WordPress nie wysyła maili. Formularz kontaktowy milczy: diagnoza krok po kroku

Formularz pokazuje „Dziękujemy, wiadomość została wysłana”, a w skrzynce nic. Albo klient pisze, że wysłał zapytanie dwa razy, a do Ciebie nie dotarło żadne. Kiedy WordPress nie wysyła maili, strona nie jest zepsuta w zwykłym sensie: wygląda normalnie, formularz działa, tylko wiadomości giną po drodze. Dlatego ten problem trwa często tygodniami, zanim ktoś go zauważy. Poniżej opisujemy, jak ustalić, w którym miejscu wiadomość znika, i jak ustawić wysyłkę tak, żeby nie znikała więcej.

Ten poradnik jest techniczny i opisuje diagnozę krok po kroku. Jeśli szukasz ogólnych zasad dobrego formularza (ochrona przed spamem, RODO, liczba pól), zobacz artykuł Formularz kontaktowy, który nie gubi zapytań.

Dlaczego WordPress nie wysyła maili: jak to działa pod spodem

WordPress nie ma własnego serwera pocztowego. Każda wiadomość (z formularza, reset hasła, powiadomienie o zamówieniu) przechodzi przez funkcję wp_mail(), która korzysta z biblioteki PHPMailer. Domyślnie PHPMailer przekazuje wiadomość funkcji PHP mail(), a ta oddaje ją programowi pocztowemu na serwerze hostingu. Dokumentacja WordPressa mówi wprost, że WordPress nigdy nie dostarczał własnego programu do wysyłki poczty i że bez działającego programu na serwerze poczta nie wyjdzie, chyba że skonfigurujesz wysyłkę przez zewnętrzny serwer SMTP.

Wysyłka przez mail() ma dwie słabości. Po pierwsze, serwer hostingu wysyła wiadomość w imieniu Twojej domeny, ale nie loguje się do Twojej skrzynki, więc serwer odbiorcy nie ma dowodu, że to naprawdę Ty. Po drugie, domyślnym nadawcą jest adres typu [email protected], którego zwykle nikt nie założył. Od 1 lutego 2024 r. Gmail wymaga od każdego nadawcy co najmniej rekordu SPF lub podpisu DKIM, a od wysyłających ponad 5 000 wiadomości dziennie obu tych zabezpieczeń i DMARC. Mała strona tego progu nie przekracza, ale wiadomość bez uwierzytelnienia i tak ma dużą szansę trafić do spamu albo zostać odrzucona.

Objawy: gdzie ginie wiadomość

Najczęstsze przyczyny

Kolejność według częstości to nasza ocena na podstawie zgłoszeń na forach wsparcia wtyczek i dokumentacji. Na konkretnej stronie może być inaczej.

1. Wysyłka przez mail() bez uwierzytelnienia (bardzo często). Wiadomość wychodzi, ale serwery Gmaila, Onetu czy WP.pl traktują ją jako podejrzaną.
2. Nadawca spoza domeny (często). Formularz ustawia jako nadawcę adres, który klient wpisał w polu e-mail. Dla serwera odbiorcy to podszywanie się pod cudzą domenę.
3. Brakujące lub błędne rekordy SPF, DKIM, DMARC (często). Np. SPF wymienia serwer poczty Google, ale nie serwer hostingu, z którego wysyła strona.
4. Hosting blokuje lub limituje wysyłkę (czasem). Część hostingów wyłącza mail(), ogranicza liczbę wiadomości na godzinę albo blokuje konto po wykryciu spamu.
5. Lokalne dostarczanie przy poczcie u innego dostawcy (czasem, ale bardzo mylące). Opisujemy je w kroku 7.
6. Zły adres odbiorcy w ustawieniach formularza (czasem). Stary adres pracownika, literówka, skrzynka poprzedniego wykonawcy.
7. Konflikt po aktualizacji (rzadziej). Wtyczka formularza, antyspamu lub cache po aktualizacji przestaje współpracować.

Zanim zaczniesz

• Zrób kopię strony (pliki i baza), zanim zainstalujesz wtyczkę SMTP albo zmienisz ustawienia formularza. Jak ją zrobić, piszemy w artykule Kopie zapasowe: zasada 3-2-1.
• Przygotuj trzy dostępy: panel WordPressa, panel hostingu i panel, w którym zarządzasz DNS domeny (to może być hosting, rejestrator domeny albo Cloudflare).
• Przygotuj dwa adresy testowe: jeden na Gmailu lub innym darmowym serwisie i jeden w Twojej domenie. Część problemów widać tylko na jednym z nich.
• Zapisz, od kiedy problem występuje. Data często wskazuje przyczynę: aktualizacja, zmiana poczty na Google Workspace, przeprowadzka strony.

Diagnoza krok po kroku

Krok 1. Sprawdź, czy zgłoszenie w ogóle zostało wysłane

Wyślij formularz sam, z adresu na Gmailu, w oknie prywatnym przeglądarki. Zanotuj dokładną godzinę.

Co powinieneś zobaczyć: komunikat o wysłaniu wiadomości. Jeśli zamiast tego widzisz komunikat o błędzie, przejdź od razu do kroku 2. Jeśli formularz w ogóle nie reaguje na kliknięcie, problem leży w samym formularzu, nie w poczcie: przejdź do kroku 8.

Sprawdź też, czy wtyczka formularza zapisuje zgłoszenia w panelu. Robi to np. Fluent Forms czy Gravity Forms, a do Contact Form 7 służy dodatek Flamingo. Jeśli zgłoszenie jest w panelu, a nie ma go w skrzynce, masz pewność, że problem dotyczy poczty, a nie formularza. Masz też zgłoszenia, które dotąd przepadały.

Krok 2. Włącz dziennik poczty i wyślij wiadomość testową

Domyślnie WordPress nie zapisuje, co i dokąd wysłał. Dziennik poczty zmienia zgadywanie w konkretną odpowiedź. Najprostsza droga to wtyczka SMTP z dziennikiem, np. FluentSMTP (w całości darmowa, zapisuje każdą wiadomość razem z odpowiedzią serwera i pozwala ponownie wysłać te nieudane) albo WP Mail SMTP.

1. Zainstaluj wtyczkę i na razie nie zmieniaj sposobu wysyłki. Wybierz opcję wysyłki domyślnej (PHP mail), żeby sprawdzić stan obecny.
2. Włącz dziennik wiadomości w ustawieniach wtyczki.
3. Użyj funkcji „wyślij e-mail testowy” na adres na Gmailu, a potem wyślij jeszcze raz formularz ze strony.

Co powinieneś zobaczyć: w dzienniku dwie wiadomości ze statusem „wysłano”. Jeśli status to „błąd”, przeczytaj komunikat obok. Could not instantiate mail function oznacza, że hosting nie pozwala wysyłać przez mail(): przejdź do kroku 6. Jeśli status to „wysłano”, a wiadomości nie ma w skrzynce, WordPress zrobił swoje, a wiadomość zginęła dalej: przejdź do kroku 3.

Krok 3. Sprawdź nadawcę i odbiorcę w ustawieniach formularza

W Contact Form 7 te pola są w zakładce Wiadomość przy edycji formularza. W innych wtyczkach szukaj ustawień powiadomień (Notifications, Powiadomienia e-mail).

• Do (odbiorca): aktualny adres, który ktoś naprawdę czyta. Sprawdź literówki.
• Od (nadawca): adres w Twojej domenie, najlepiej istniejąca skrzynka, np. [email protected] albo [email protected]. Nigdy adres z pola, które wypełnia klient.
• Odpowiedz do (Reply-To): tu wstaw adres klienta. W Contact Form 7 dopisz w polu Dodatkowe nagłówki linię Reply-To: [your-email], gdzie your-email to nazwa pola e-mail w Twoim formularzu. Dzięki temu „Odpowiedz” w programie pocztowym nadal trafi do klienta.

Contact Form 7 ma wbudowany walidator konfiguracji. Jeśli nad formularzem widzisz ostrzeżenie, że adres nadawcy nie należy do domeny strony, to jest właśnie ten problem.

Krok 4. Przeczytaj nagłówki wiadomości, która trafiła do spamu

Jeśli wiadomość jest w spamie, sama mówi, dlaczego. W Gmailu otwórz ją, kliknij trzy kropki i wybierz Pokaż oryginał. Na górze zobaczysz trzy wiersze: SPF, DKIM i DMARC, każdy z wynikiem.

Krok 5. Sprawdź rekordy DNS domeny

Rekordy sprawdzisz w panelu DNS albo darmowym narzędziem online do testowania SPF i DMARC (np. MXToolbox). Najczęstsze błędy:

• Dwa rekordy SPF. Domena może mieć tylko jeden rekord TXT zaczynający się od v=spf1. Dwa takie rekordy to błąd i SPF przestaje działać w całości. Połącz je w jeden.
• SPF bez serwera, który wysyła. Jeśli poczta jest w Google Workspace, a strona wysyła przez mail() hostingu, SPF musi obejmować oba serwery. Prościej jest wysyłać ze strony przez SMTP Google (krok 6), bo wtedy wystarczy wpis Google.
• Za dużo wpisów include. Sprawdzenie SPF może wymagać najwyżej 10 zapytań DNS (RFC 7208). Domeny, które przez lata dopisywały kolejne usługi, ten limit przekraczają.
• Brak DMARC. Na start wystarczy rekord TXT dla _dmarc.twojadomena.pl z wartością v=DMARC1; p=none; rua=mailto:[email protected]. Poniżej, co oznacza każda część:

v=DMARC1                         ← wersja standardu, zawsze ta sama
p=none                           ← na razie tylko obserwuj, niczego nie odrzucaj
rua=mailto:[email protected]  ← dokąd serwery mają wysyłać raporty

Zmiany w DNS działają zwykle po kilku minutach, ale mogą potrzebować do kilkunastu godzin. Szerzej o tych rekordach piszemy w artykule Poczta firmowa: SPF, DKIM, DMARC.

Krok 6. Przełącz wysyłkę na SMTP

To naprawia większość przypadków na stałe. Strona loguje się do prawdziwej skrzynki i wysyła wiadomość tak, jak robi to program pocztowy.

1. Załóż skrzynkę, z której strona będzie wysyłać, np. [email protected]. Może to być skrzynka na hostingu albo konto w Google Workspace lub Microsoft 365.
2. W ustawieniach wtyczki SMTP wybierz „Inny SMTP” (lub odpowiednik) i wpisz dane serwera od dostawcy poczty: adres serwera wychodzącego, port 465 z SSL albo 587 z TLS, login (zwykle pełny adres e-mail) i hasło.
3. Jako adres nadawcy wpisz tę samą skrzynkę i zaznacz opcję wymuszenia nadawcy (Force From Email). Wtedy żadna wtyczka nie podstawi innego adresu.
4. Wyślij e-mail testowy na Gmaila i na adres w swojej domenie, potem sprawdź nagłówki jak w kroku 4.

Co powinieneś zobaczyć: wiadomość w skrzynce odbiorczej, a w nagłówkach SPF i DKIM z wynikiem PASS.

Jeśli test kończy się błędem połączenia (timeout, Connection refused), hosting może blokować połączenia wychodzące na porty pocztowe. Zapytaj obsługę, który serwer SMTP wolno używać. Alternatywą jest wysyłka przez API dostawcy poczty transakcyjnej (np. Brevo, Mailgun, Amazon SES), którą obsługują obie wymienione wtyczki. Jeśli błąd dotyczy logowania, sprawdź hasło. Przy kontach Google i Microsoft z logowaniem dwuetapowym zwykłe hasło nie zadziała: potrzebne jest hasło do aplikacji albo połączenie przez OAuth, które wtyczki konfigurują kreatorem.

Hasło do skrzynki leży w bazie WordPressa. Obie wtyczki pozwalają przenieść je do pliku wp-config.php, co jest bezpieczniejsze. Instrukcja jest w dokumentacji wtyczki.

Krok 7. Poczta w Google Workspace lub Microsoft 365? Wyłącz lokalne dostarczanie

To przypadek, który potrafi zająć godziny. Objawy: wiadomości ze strony dochodzą na Gmaila, ale nie na [email protected]. Dziennik poczty pokazuje „wysłano”. W spamie nic nie ma.

Przyczyna: hosting nadal uważa się za serwer pocztowy Twojej domeny, bo kiedyś tam była poczta. Gdy strona wysyła wiadomość na adres w tej domenie, serwer nie pyta DNS, gdzie jest poczta, tylko wrzuca ją do lokalnej, nieużywanej skrzynki. Wiadomości nie opuszczają serwera.

• DirectAdmin: w ustawieniach rekordów MX domeny odznacz opcję lokalnego serwera pocztowego (Local Mail Server).
• cPanel: w Email Routing wybierz Remote Mail Exchanger.
• Inne panele: zapytaj obsługę hostingu o wyłączenie lokalnej obsługi poczty dla domeny, bo poczta jest u innego dostawcy.

Wysyłka przez SMTP Google lub Microsoft (krok 6) też omija ten problem, bo wiadomość wychodzi od razu z ich serwerów.

Krok 8. Formularz przestał działać po aktualizacji

• Sprawdź konsolę przeglądarki. Na stronie z formularzem naciśnij F12, otwórz zakładkę Konsola i wyślij formularz. Czerwone błędy JavaScript oznaczają konflikt skryptów, często z wtyczką optymalizującą (łączenie i opóźnianie skryptów).
• Sprawdź klucze CAPTCHA. Klucze reCAPTCHA i Cloudflare Turnstile są przypisane do domeny. Po zmianie domeny lub przeprowadzce formularz może odrzucać każde zgłoszenie jako spam.
• Wyczyść cache wtyczki, hostingu i Cloudflare. Zapisana w pamięci podręcznej strona może zawierać nieważny już token formularza.
• Wyłącz kolejno wtyczki optymalizacji, antyspamu i bezpieczeństwa, najlepiej na kopii testowej, i za każdym razem wyślij formularz. Jeśli strona po aktualizacji pokazuje błąd zamiast formularza, zobacz poradnik Błąd krytyczny na stronie WordPress.

Kiedy przestać i poprosić o pomoc

• Dziennik poczty pokazuje wiadomości, których nikt nie wysyłał, np. setki maili do obcych adresów. To typowy ślad włamania: strona rozsyła spam. Zobacz WordPress po włamaniu: pierwsze 24 godziny.
• Hosting zablokował wysyłkę poczty za spam albo przekroczenie limitu. Bez ustalenia przyczyny blokada wróci.
• Domena lub serwer są na czarnych listach antyspamowych. Usunięcie z listy wymaga najpierw usunięcia przyczyny.
• Nie masz dostępu do DNS domeny, np. bo domena jest zarejestrowana na poprzedniego wykonawcę.
• Nie dochodzą też maile z resetem hasła i nie możesz wejść do panelu. Zobacz poradnik Nie mogę zalogować się do WordPressa.

Jak zapobiegać

• Wysyłka przez SMTP z prawdziwej skrzynki od pierwszego dnia, nigdy przez domyślne mail().
• Kopia zgłoszeń w panelu. Jeśli poczta zawiedzie, zapytanie zostaje. Ustal okres przechowywania, bo to dane osobowe.
• Dziennik poczty z powiadomieniem o błędzie wysyłki. FluentSMTP i WP Mail SMTP mogą powiadomić, gdy wysyłka się nie uda.
• Automatyczne potwierdzenie dla klienta. Klient wie, że zapytanie dotarło, a Ty od razu widzisz, czy wysyłka działa.
• Test formularza co miesiąc i po każdej aktualizacji wtyczek. Opisujemy to w artykule o aktualizacjach WordPressa i wtyczek.
• SPF, DKIM i DMARC ustawione przy zakładaniu poczty, z raportami DMARC na osobny adres.

Źródła

• WordPress Developer Resources: Mail (wysyłka przez PHPMailer i mail(), SMTP, adres nadawcy) (dostęp: 10.11.2026)
• WordPress Developer Resources: wp_mail() (dostęp: 10.11.2026)
• Google, Pomoc Gmaila: Email sender guidelines (wymagania od 1.02.2024, próg 5 000 wiadomości dziennie) (dostęp: 10.11.2026)
• IETF: RFC 7208, Sender Policy Framework (jeden rekord SPF, limit 10 zapytań DNS) (dostęp: 10.11.2026)
• Contact Form 7: Setting up mail (pola Od, Do, Dodatkowe nagłówki) (dostęp: 10.11.2026)
• WordPress.org Plugins: FluentSMTP (dziennik i ponowna wysyłka w wersji darmowej) (dostęp: 10.11.2026)