Formularz kontaktowy WordPress nie wysyła wiadomości – jak to sprawdzić

Strona działa. Formularz po kliknięciu „Wyślij” pokazuje zielony komunikat „Dziękujemy, wiadomość została wysłana”. A na skrzynce nic. Nie dziś, nie wczoraj – możliwe, że od trzech miesięcy.

To awaria, której nikt nie zgłasza. Kiedy pada strona, telefon dzwoni w ciągu godziny. Kiedy przestaje działać formularz, nie dzwoni nikt – bo osoba, która go wypełniła, jest przekonana, że napisała, a Ty jesteś przekonany, że nikt nie pisze. Zapytania nie przychodzą, ale „nie przyszło” nie zostawia śladu w żadnym logu. Nie wiesz, ilu zapytań nie dostałeś, i właśnie dlatego ta awaria potrafi trwać miesiącami.

Ten poradnik prowadzi od pięciominutowego testu przez trzy warstwy, w których wiadomość może zginąć (przeglądarka, PHP, poczta), po konfigurację SMTP oraz rekordy SPF, DKIM i DMARC. Na końcu znajdziesz sposób na to, żeby sprawdzać formularz na stałe – bo jednorazowa naprawa nie chroni przed drugą taką ciszą.

Wykonaj po kolei. Cały test robisz z zewnątrz, jak zwykły odwiedzający.

1. Wyślij zgłoszenie spoza firmy. Z prywatnego telefonu, w sieci komórkowej (nie na firmowym Wi-Fi), z adresu na obcej domenie – Gmail, WP.pl, Onet. W treści wpisz godzinę wysłania.
2. Zapamiętaj, co pokazała strona. Komunikat sukcesu? Komunikat błędu? Czy nic – kółko kręci się w nieskończoność albo strona przeładowała się bez słowa? To trzy różne diagnozy.
3. Sprawdź skrzynkę docelową w całości. Folder Spam, w Gmailu także zakładki Oferty i Powiadomienia, oraz reguły przenoszenia wiadomości do katalogów. Wiadomość „nieodebrana” bywa odebrana i schowana.
4. Sprawdź, czy wtyczka zapisała zgłoszenie w panelu. Forminator ma sekcję Zgłoszenia, WPForms – Wpisy, Contact Form 7 nie zapisuje nic bez dodatkowej wtyczki. Zapis jest, a maila nie ma? Formularz zadziałał i padła poczta. Nie ma zapisu? Problem jest wcześniej.
5. Wyślij drugie zgłoszenie na inny adres odbiorcy – najlepiej u innego dostawcy niż pierwszy (skrzynka na Twoim hostingu kontra Gmail). Jeśli dochodzi tylko na jeden z nich, przyczyna jest po stronie dostarczania, a nie wysyłki.
6. Otwórz ustawienia formularza i przeczytaj adres odbiorcy znak po znaku. Literówka w adresie i awaria serwera pocztowego wyglądają z zewnątrz identycznie.
7. Wyślij formularz z otwartą konsolą przeglądarki (F12 → zakładki Konsola i Sieć). Czerwony błąd JavaScriptu albo żądanie z kodem 403, 404 czy 500 znaczy, że zgłoszenie nie dotarło nawet do WordPressa.
8. Zajrzyj do dziennika wysyłki, jeśli masz wtyczkę SMTP z logiem. Wpis „wysłano” przy braku wiadomości na skrzynce przenosi całą diagnostykę na warstwę poczty.

Wynik testu kieruje do konkretnej sekcji:

Zgłoszenie z formularza pokonuje trzy odcinki i każdy z nich ma inne przyczyny awarii, inne objawy i inne narzędzia diagnostyczne. Mieszanie ich to najczęstszy powód, dla którego samodzielna naprawa trwa cały dzień: ktoś konfiguruje SMTP, choć wiadomość nigdy nie dotarła do PHP.

Ten odcinek psuje się najczęściej po aktualizacji WordPressa lub wtyczki ({{URL_TEMAT_1}}): jeden błąd JavaScriptu w motywie albo innej wtyczce zatrzymuje skrypt formularza, zanim ten zdąży cokolwiek wysłać. Druga przyczyna to cache – wtyczka cache lub CDN serwuje zapisaną wcześniej wersję strony ze starym znacznikiem bezpieczeństwa, a serwer odrzuca takie zgłoszenie. Trzecia to zapora albo wtyczka bezpieczeństwa blokująca żądania POST do admin-ajax.php lub /wp-json/ – a właśnie tamtędy chodzą nowoczesne formularze.

Tu zapada decyzja, czy wiadomość w ogóle powstanie. Na tanich hostingach funkcja mail() bywa wyłączona wpisem w disable_functions albo objęta limitem wiadomości na godzinę, po przekroczeniu którego wysyłka milknie do północy. Ten sam mechanizm sprawia, że sklep przestaje wysyłać maile o zamówieniach ({{URL_TEMAT_2}}) – tyle że tam skutki widać szybciej, bo klient dzwoni, że nie dostał potwierdzenia.

Tu decyduje serwer, nad którym nie masz kontroli. Wiadomość może zostać odrzucona przy przyjęciu, uznana za spam, trafić do kwarantanny administratora poczty firmowej albo zginąć na przekierowaniu skrzynki. Wszystkie te przypadki wyglądają identycznie: strona mówi, że wysłała, a Ty nie masz nic.

WordPress wysyła pocztę funkcją wp_mail(). Ta przekazuje wiadomość bibliotece PHPMailer, a ta domyślnie korzysta z funkcji mail() samego PHP, czyli oddaje wiadomość programowi pocztowemu zainstalowanemu na serwerze. Nikt na tej drodze nie potwierdza, że wiadomość dotarła do adresata – potwierdzany jest wyłącznie fakt jej przekazania dalej.

Dlatego wp_mail() zwracające true znaczy tylko tyle, że wiadomość udało się przekazać do wysyłki. Wtyczka formularza czyta tę wartość i na jej podstawie pokazuje odwiedzającemu komunikat sukcesu. Cała reszta drogi jest dla WordPressa niewidoczna.

Kiedy przekazanie się nie uda, WordPress uruchamia akcję wp_mail_failed z obiektem błędu. Domyślnie nikt jej nie słucha, więc powód znika. Kilka linii w pliku motywu potomnego albo we własnej wtyczce zapisuje go do logu:

Żeby log powstał, w pliku wp-config.php musi być włączone zapisywanie błędów:

Wpisy trafią do wp-content/debug.log. Komunikat „SMTP connect() failed” wskazuje na dane logowania, „Could not instantiate mail function” – na zablokowaną funkcję mail() po stronie hostingu.

Wysyłka funkcją mail() jest anonimowa: serwer podaje się za nadawcę z Twojej domeny, ale niczym tego nie potwierdza – i serwery odbiorców mają powody, żeby traktować taką pocztę podejrzliwie. SMTP to zmienia: WordPress loguje się do konkretnej skrzynki i wysyła wiadomość jako ona, tak jak program pocztowy na Twoim komputerze.

Hasło do konta pocztowego wpisane w ustawienia wtyczki leży w bazie danych strony – razem z każdą jej kopią zapasową. U dostawców z logowaniem dwuskładnikowym i tak nie zadziała: Google i Microsoft wymagają hasła aplikacji albo połączenia przez OAuth, a dostawca transakcyjny – klucza API, który da się unieważnić bez zmiany hasła do poczty.

Popularne wtyczki SMTP pozwalają wynieść sekret z bazy do pliku konfiguracyjnego. WP Mail SMTP robi to stałymi w wp-config.php:

To trzy wpisy w strefie DNS Twojej domeny. Odpowiadają serwerowi odbiorcy na pytanie, czy wiadomość podpisana Twoją domeną naprawdę pochodzi od Ciebie. Bez nich nawet bezbłędnie ustawiony SMTP dostarcza wiadomości do folderu spam – albo nie dostarcza wcale.

Jeden rekord tekstowy z listą serwerów uprawnionych do wysyłania poczty:

Dwie pułapki, które widać w połowie przypadków. Pierwsza: dwa rekordy SPF na jednej domenie to błąd – sprawdzenie kończy się niepowodzeniem tak samo, jakby nie było żadnego. Dodając nowego dostawcę, rozszerzasz istniejący rekord, nie dopisujesz drugiego. Druga: standard dopuszcza maksymalnie dziesięć zapytań DNS przy sprawdzaniu, a każde include: je zużywa. Domena z pięcioma narzędziami marketingowymi potrafi ten limit przekroczyć i wtedy SPF przestaje działać dla wszystkich naraz.

Zakończenie -all znaczy „odrzuć pocztę z innych serwerów”, ~all – „oznacz jako podejrzaną”. Przy pierwszej konfiguracji bezpieczniej zacząć od ~all.

Serwer wysyłający podpisuje wiadomość kluczem prywatnym, a klucz publiczny publikujesz w DNS. Odbiorca sprawdza podpis i przy okazji upewnia się, że treść nie została po drodze zmieniona. Klucz i selektor generuje dostawca poczty – Twoja rola sprowadza się do wklejenia rekordu do strefy DNS. DKIM ma jedną istotną przewagę nad SPF: przetrwa przekierowanie wiadomości, bo nie zależy od adresu serwera, który ją przekazuje.

Rekord mówi odbiorcom, co robić z wiadomością, która nie przeszła weryfikacji, i gdzie wysyłać raporty:

Polityka p=none niczego nie blokuje – służy do obserwacji. Dopiero gdy z raportów wynika, że cała Twoja poczta przechodzi poprawnie, przechodzisz na p=quarantine, a potem p=reject. DMARC wymaga jeszcze wyrównania: domena widoczna w polu „Od” musi zgadzać się z domeną potwierdzoną przez SPF albo przez podpis DKIM. To dlatego wysyłanie wiadomości w imieniu odwiedzającego kończy się źle – o tym w następnej sekcji.

Rekordy sprawdzisz jednym poleceniem w terminalu (w Windows odpowiednikiem jest nslookup -type=TXT):

Od lutego 2024 Google wymaga od każdego nadawcy poczty na adresy Gmail uwierzytelnienia SPF albo DKIM. Ostrzejszy zestaw – SPF, DKIM, DMARC, jednoklikowa rezygnacja i utrzymanie wskaźnika zgłoszeń spamu poniżej 0,3% – obowiązuje nadawców masowych, czyli od 5000 wiadomości dziennie. Formularz kontaktowy do tego progu nie dochodzi, więc te dodatkowe wymagania go nie dotyczą; wymóg SPF albo DKIM dotyczy go w pełni.

Trudny do wykrycia układ: formularz wysyła na kontakt@twojadomena.pl, a ta skrzynka ma przekierowanie na prywatnego Gmaila. Serwer przekierowujący przekazuje wiadomość dalej z oryginalnym nadawcą, a Gmail widzi, że ten serwer nie figuruje w SPF nadawcy. Efekt: wiadomość dociera na skrzynkę firmową i ginie po przekierowaniu.

Objaw rozpoznawczy: zgłoszenia są w archiwum skrzynki firmowej, ale nie ma ich w Gmailu. Rozwiązanie: pobieraj pocztę przez IMAP zamiast ją przekierowywać albo sprawdź u dostawcy, czy obsługuje przepisywanie nadawcy przy przekierowaniach.

Domyślnie WordPress wysyła pocztę jako wordpress@twojadomena.pl z nazwą „WordPress”. Ta skrzynka zwykle nie istnieje, więc odbicia i komunikaty o błędach dostarczania nie trafiają do nikogo – awaria poczty przestaje zostawiać jakikolwiek ślad.

Gorszy, a bardzo popularny wariant to wstawienie w pole „Od” adresu podanego przez odwiedzającego. Wygląda wygodnie – wiadomość ma od razu właściwego nadawcę – ale technicznie jest to podszywanie się pod cudzą domenę. Serwer wysyłający należy do Twojego hostingu, a w polu nadawcy stoi gmail.com: sprawdzenie SPF nie przechodzi, a jeśli domena odwiedzającego ma DMARC z polityką quarantine lub reject, wiadomość zostaje zatrzymana. Klienci z Gmaila piszą, a klienci z firmowych domen znikają.

Poprawny układ pól wygląda tak:

Adres nadawcy zmienisz globalnie filtrami WordPressa:

Mechanizm jest wspólny, różnią się nazwy pól i to, czy wtyczka zostawia po zgłoszeniu jakikolwiek ślad.

Brak zapisu zgłoszeń to największe ryzyko tej wtyczki: gdy poczta padnie, po wiadomości nie zostaje nic. Wtyczka Flamingo tego samego autora dokłada historię zgłoszeń i warto ją zainstalować niezależnie od tego, czy coś się dziś psuje.

Contact Form 7 ma wbudowaną kontrolę konfiguracji, która ostrzega między innymi przed wstawieniem adresu odwiedzającego w polu „Od”. Ostrzeżenie jest łatwe do przeoczenia, bo formularz mimo niego działa. W zakładce z ustawieniami wiadomości adres odwiedzającego wpisuje się do pola dodatkowych nagłówków jako Reply-To, a nie do pola nadawcy.

Druga pułapka: wtyczka wysyła zgłoszenie przez REST API WordPressa. Wtyczka bezpieczeństwa, która „na wszelki wypadek” wyłącza REST API dla niezalogowanych, zatrzymuje formularz na poziomie przeglądarki – z kodem 403 i bez żadnego komunikatu dla odwiedzającego.

Zgłoszenia lądują w panelu, więc zanim uznasz, że formularz nie działa, sprawdź listę wpisów: jeśli są, problem jest wyłącznie pocztowy. W ustawieniach powiadomień uważaj na pola dynamiczne – wstawienie znacznika z adresem odwiedzającego w polu nadawcy powoduje dokładnie ten problem, który opisuje sekcja o adresie nadawcy. Druga typowa przyczyna to dwie wtyczki SMTP zainstalowane równolegle; przechwytują tę samą funkcję i wygrywa ta, która załadowała się później.

Wtyczka wysyła dwie różne wiadomości: powiadomienie do administratora i autoodpowiedź do osoby wypełniającej. Mają osobne ustawienia i osobne przełączniki, więc łatwo wyłączyć jedno i przez tydzień być przekonanym, że działa drugie. Domyślnym nadawcą jest adres administratora WordPressa – jeśli jest to adres na obcej domenie (na przykład prywatny Gmail), wracasz do problemu z uwierzytelnieniem.

W Elementor Forms, Gravity Forms i Fluent Forms obowiązują te same zasady. Sprawdzasz zawsze trzy rzeczy: czy wtyczka zapisuje zgłoszenia, jaki adres wstawia w pole nadawcy i czy adres odbiorcy istnieje.

Zabezpieczenie przed botami działa na tym samym odcinku co formularz i potrafi odrzucać zgłoszenia, których nikt nie chciał odrzucać. Najczęstsze przypadki:

• reCAPTCHA v3 z wysokim progiem. Ocenia zachowanie odwiedzającego liczbą i odrzuca wszystko poniżej progu. Osoba z blokerem skryptów, w trybie prywatnym albo w firmowej sieci dostaje niską ocenę i jest traktowana jak bot.
• Klucze reCAPTCHA związane z inną domeną. Po przejściu na HTTPS, zmianie adresu z www na bez www albo po migracji klucze przestają pasować. Formularz przestaje się wysyłać z dnia na dzień, bez żadnej zmiany w jego ustawieniach.
• Akismet oznaczający zgłoszenia jako spam. W Contact Form 7 wiadomość oznaczona jako spam nie zostaje wysłana i – bez wtyczki zapisującej zgłoszenia – nie zostaje po niej ślad.
• Pole pułapka wypełniane przez menedżera haseł. Ukryte pole, które ma zostać puste, bywa automatycznie uzupełniane przez przeglądarkę lub menedżera haseł. Zgłoszenie od realnej osoby zostaje uznane za robota.
• Zapora aplikacyjna i filtry treści. Reguły blokujące adresy URL w treści odrzucają zapytania od osób, które podają link do swojej strony – czyli zwykle od najlepszych leadów.

Naprawa jednorazowa rozwiązuje dzisiejszy problem i nie chroni przed kolejnym. Formularz psuje się cicho przy każdej aktualizacji wtyczki, zmianie hostingu, zmianie dostawcy poczty i każdej korekcie DNS. Sześć rzeczy, które zamieniają to w wykrywalną awarię:

1. Włącz zapisywanie zgłoszeń w bazie. Druga, niezależna droga: nawet gdy poczta przestanie działać, zapytanie zostaje w panelu.
2. Włącz dziennik wysyłki e-maili. Widzisz, czy wiadomość powstała i co odpowiedział serwer pocztowy.
3. Dodaj kopię na drugą skrzynkę u innego dostawcy. Różnicę między nimi zauważysz tego samego dnia.
4. Ustaw automatyczny test cykliczny – wysłanie zgłoszenia i sprawdzenie, czy dotarło. Monitoring dostępności tego nie zastępuje: strona kontaktu odpowiada kodem 200 również wtedy, gdy formularz od miesiąca nic nie wysyła.
5. Testuj po każdej aktualizacji wtyczki formularza, wtyczki SMTP, wtyczki bezpieczeństwa i motywu.
6. Zbieraj raporty DMARC na adres z pola rua. Pokazują, ile Twojej poczty jest odrzucane i przez kogo, zanim zauważysz to po ciszy w skrzynce.

Punkty 1–3 ustawia się raz i działają same. Punkty 4–6 to praca cykliczna – i to właśnie one najczęściej wypadają z planu, kiedy nikt konkretny za nie nie odpowiada. To jeden z punktów, na który warto patrzeć, porównując, co powinna obejmować opieka nad stroną ({{URL_TEMAT_7}}).

Sensowna odpowiedź brzmi: nie wiesz. I to jest właśnie ten koszt.

Awaria strony jest zdarzeniem: ma początek, koniec i świadków. Awaria formularza nie ma żadnego z tych trzech elementów. Nikt nie zgłasza, że wiadomość nie doszła, bo z perspektywy nadawcy doszła. Nie ma spadku, który dałoby się zauważyć, bo nie masz liczby odniesienia – zapytania nie przychodzą w równym rytmie, więc dwa spokojne tygodnie wyglądają na dwa spokojne tygodnie.

Trzy rzeczy, które można sprawdzić zamiast zgadywać: liczba zapisanych zgłoszeń miesiąc do miesiąca, ruch na stronie kontaktu zestawiony z liczbą zapytań (rosnące wejścia przy stałej liczbie wiadomości to sygnał) oraz koszt reklam. Ten ostatni jest policzalny co do złotówki: płacąc za ruch, płacisz też za wypełnienia formularza, które nigdzie nie docierają.

Test z początku artykułu i konfiguracja SMTP to prace w zasięgu osoby, która ogarnia panel WordPressa. Są jednak sytuacje, w których samodzielne próby kosztują więcej, niż oszczędzają:

• Nie masz pewnego dostępu do DNS domeny. SPF, DKIM i DMARC to zmiany w strefie DNS. Pomyłka w rekordzie MX przy okazji edycji zatrzymuje całą pocztę firmy, nie tylko formularz – i trwa to tyle, ile propagacja zmiany.
• Chcesz ustawić DMARC na reject. Trzeba wcześniej znać wszystkich nadawców używających Twojej domeny: pocztę firmową, newsletter, system fakturowy, CRM, sklep. Pominięcie jednego znaczy, że jego wiadomości przestają docierać, a dowiadujesz się o tym od klientów.
• Formularz działa u Ciebie, a nie działa u części odbiorców. To nie jest problem konfiguracji strony, tylko dostarczalności i reputacji – diagnoza wymaga czytania nagłówków wiadomości i raportów DMARC.
• Nie wiesz, od kiedy nie działa. Pierwszym zadaniem nie jest wtedy naprawa, tylko ustalenie zakresu: ile zapytań przepadło i czy da się je odzyskać z logów serwera pocztowego.
• Hosting zablokował wysyłkę z Twojego konta. To zwykle znaczy, że strona rozsyłała spam, czyli że ktoś ma do niej dostęp. Odblokowanie wysyłki bez usunięcia przyczyny kończy się drugą blokadą w ciągu kilku dni.

W tych przypadkach sensowne są dwie drogi. Jednorazowy audyt: ktoś przechodzi całą ścieżkę zgłoszenia, sprawdza rekordy DNS, konfigurację poczty i ustawienia wtyczki, a potem mówi, co i od kiedy nie działało. Albo stała opieka techniczna, w której formularz jest testowany po aktualizacjach, a nie wtedy, gdy ktoś się zorientuje. Monitoring działania formularzy wchodzi u nas do zakresu od pakietu Opieka Biznes (649 zł netto miesięcznie); same pakiety opieki zaczynają się od 349 zł netto miesięcznie.

Niedziałający formularz to awaria bez alarmu: strona wygląda normalnie, komunikat mówi „wysłano”, a zapytania nie przychodzą. Diagnoza sprowadza się do ustalenia jednego – na którym z trzech odcinków ginie wiadomość. Brak zapisu w panelu wtyczki wskazuje na przeglądarkę, zapis bez wpisu w dzienniku wysyłki na PHP, a zapis z wpisem „wysłano” przy pustej skrzynce na pocztę: SMTP, SPF, DKIM, DMARC i adres nadawcy.

Jeśli po tym teście okaże się, że formularz nie działa, a nie wiesz od kiedy – albo jeśli wolisz mieć pewność, zanim znowu przyjdzie spokojniejszy miesiąc – sprawdzimy to za Ciebie. Przejdziemy całą ścieżkę zgłoszenia, rekordy DNS i konfigurację poczty, i powiemy, co przestało działać i kiedy. Napisz przez formularz kontaktowy – nasz testujemy regularnie, właśnie z powodów opisanych wyżej – albo zadzwoń: +48 575 067 607.