Klient wypełnia formularz, klika „Wyślij”, dostaje zielony komunikat „Twoja wiadomość została wysłana. Dziękujemy!”. I tyle. Do Ciebie nie przychodzi nic — ani do skrzynki, ani do spamu. Dowiadujesz się o tym po dwóch tygodniach, przypadkiem, kiedy ktoś dzwoni z pretensją, że „pisał i nikt nie odpowiedział”.
To jedna z najkosztowniejszych awarii, jakie może mieć strona firmowa, bo nic nie wygląda na zepsute. Strona działa, formularz działa, komunikat jest zielony. Po prostu zapytania znikają. Poniżej — dlaczego tak się dzieje i jak w kilkanaście minut ustalić, na którym etapie urywa się wiadomość.
Dlaczego formularz pisze „wysłano”, skoro nic nie doszło
Bo komunikat nie znaczy tego, co się wydaje. Contact Form 7 (i każda inna wtyczka formularza) nie wysyła maili. Przekazuje wiadomość funkcji wp_mail(), a ta oddaje ją serwerowi. Zielony komunikat pojawia się w momencie, w którym serwer przyjął zlecenie — nie w momencie, w którym wiadomość wylądowała w Twojej skrzynce.
Droga zgłoszenia ma cztery etapy, a formularz widzi tylko pierwszy:
- formularz zbiera dane i sprawdza je (walidacja, antyspam),
wp_mail()buduje wiadomość i oddaje ją serwerowi,- serwer pocztowy próbuje ją doręczyć,
- serwer odbiorcy decyduje: skrzynka odbiorcza, spam albo kosz.
Wiadomość może zginąć na każdym z nich. Raportuje tylko pierwszy. Dlatego „wysłano” to nie dowód doręczenia, tylko dowód, że formularz zrobił swoje.
Najczęstsza przyczyna: nadawca, który nie istnieje
Domyślnie WordPress wysyła pocztę jako wordpress@twojadomena.pl. Takiej skrzynki zwykle nie ma — nikt jej nie zakładał, nikt do niej nie zagląda, nie da się na nią odpisać.
Dla Gmaila czy Outlooka to sygnał ostrzegawczy. Serwer odbiorcy sprawdza, czy nadawca jest prawdziwy, bo tak właśnie zachowuje się spam: podaje adres, który nie przyjmie odpowiedzi ani zwrotki. Efekt bywa dwojaki — wiadomość ląduje w spamie albo zostaje odrzucona po cichu, bez informacji dla nadawcy.
I tu typowa pułapka: rekord SPF może być skonfigurowany bez zarzutu, a poczta i tak nie dochodzi. SPF mówi tylko tyle, że ten serwer ma prawo wysyłać w imieniu tej domeny. Nie mówi nic o tym, czy skrzynka nadawcy w ogóle istnieje. To dwie różne rzeczy i jedna nie zastępuje drugiej.
Poprawne ustawienie wygląda tak:
- Od (From): prawdziwa skrzynka w Twojej domenie, np.
kontakt@twojadomena.pl. - Odpowiedz do (Reply-To): adres klienta z formularza — dzięki temu klikasz „Odpowiedz” i piszesz prosto do niego.
- Do (To): skrzynka, którą faktycznie czytasz.
Nigdy odwrotnie. Jeśli ustawisz nadawcę na adres klienta, Twój serwer zacznie wysyłać wiadomości „w imieniu” gmail.com — a polityka DMARC Gmaila takie wiadomości odrzuca. To najszybszy sposób, żeby formularz przestał działać na dobre.
Jak ustalić, gdzie urywa się wiadomość
Zamiast zgadywać, zawęź problem. Pięć kroków, każdy po kilka minut:
- Wyślij test z panelu. Każda wtyczka SMTP ma narzędzie „Email Test”. Jeśli test dochodzi, a zgłoszenia z formularza nie — poczta działa, a problem jest w formularzu. Jeśli nie dochodzi nawet test, problem jest w wysyłce.
- Sprawdź nadawcę. W ustawieniach formularza, w zakładce z wiadomością. Jeśli widzisz tam
wordpress@, masz dużą szansę, że to właśnie to. - Zajrzyj w dziennik błędów wtyczki SMTP. Nieudane wysyłki zostawiają tam ślad z treścią błędu serwera — zwykle mówi wprost, co odrzucono.
- Przetestuj na dwie różne skrzynki. Gmail i Twoja firmowa poczta mogą zachować się zupełnie inaczej wobec tej samej wiadomości.
- Sprawdź własne filtry. Reguła sprzed roku, która przenosi wiadomości „ze strony” do podfolderu, działa cicho i skutecznie.
Antyspam, który odrzuca zgłoszenia po cichu
Druga klasa przyczyn nie ma z pocztą nic wspólnego: zgłoszenie nigdy nie dociera do etapu wysyłki, bo zostaje uznane za spam.
Mechanizmy takie jak Cloudflare Turnstile czy reCAPTCHA dokładają do formularza ukryte pole z tokenem. Bez tokenu wtyczka traktuje wysyłkę jako bota i blokuje ją. Problem w tym, że token potrafi się nie pojawić z powodów, które nie mają nic wspólnego z użytkownikiem — na przykład gdy na jednej stronie stoją dwa formularze przełączane zakładkami i jeden z nich jest ukryty. Widget nie renderuje się w ukrytym kontenerze i przy okazji psuje ten drugi.
Z zewnątrz wygląda to tak: klient dostaje komunikat „przynajmniej jedno pole zawiera błąd”, mimo że wypełnił wszystko. Albo — gorzej — formularz pisze, że wysłał, a zgłoszenie znika. Objaw bywa losowy, bo czasem widget zdąży się załadować, a czasem nie.
Jak to rozpoznać: otwórz stronę z formularzem i sprawdź, czy pole antyspamu w ogóle się wyświetla. Jeśli w miejscu widgetu jest pusto, a formularz mimo to prosi o weryfikację — masz przyczynę.
SMTP, czyli wysyłka przez prawdziwą skrzynkę
Domyślna wysyłka przez mail() serwera to najsłabsze ogniwo: brak uwierzytelnienia, brak logów, brak informacji zwrotnej. SMTP odwraca sytuację — WordPress loguje się do Twojej skrzynki i wysyła przez nią, tak samo jak program pocztowy.
Co trzeba przygotować:
- adres serwera — zwykle nazwa serwera hostingowego, nie
mail.twojadomena.pl. To częsta pomyłka: rekord MX może wskazywać na jedną nazwę, a wysyłka działać na innej. Właściwą znajdziesz w panelu hostingu, - port i szyfrowanie — 465 z SSL albo 587 z TLS,
- login — pełny adres e-mail, nie sama nazwa użytkownika,
- hasło do tej skrzynki,
- adres nadawcy — ten sam, z którego wysyłasz, plus opcja wymuszenia go („Force From”), żeby wtyczki nie podmieniały go po swojemu.
Po skonfigurowaniu wyślij test z panelu i dopiero potem jedno prawdziwe zgłoszenie z formularza. Dwa osobne testy, bo sprawdzają dwie różne rzeczy.
Siatka bezpieczeństwa: zapisuj zgłoszenia w bazie
Niezależnie od tego, czy poczta działa, zgłoszenia powinny zapisywać się na stronie. Wtyczki takie jak Contact Form CFDB7 robią to automatycznie: każde wysłane zapytanie ląduje w bazie i widzisz je w panelu.
To kosztuje kwadrans, a zmienia charakter awarii. Z „straciliśmy nieznaną liczbę zapytań i nie wiemy, od kogo” robi się „maile nie dochodziły przez tydzień, oto lista ośmiu osób do oddzwonienia”. Przy jednym odzyskanym kliencie ta wtyczka zwraca się wielokrotnie.
Krótka lista kontrolna
- nadawca to istniejąca skrzynka w Twojej domenie, nie
wordpress@, - adres klienta siedzi w Reply-To, nie w polu nadawcy,
- wysyłka idzie przez SMTP, nie przez
mail(), - pole antyspamu faktycznie się renderuje,
- zgłoszenia zapisują się w bazie,
- raz na kwartał wysyłasz sobie testowe zgłoszenie z formularza.
Ostatni punkt jest najtańszy i najczęściej pomijany. Formularz to jedyny element strony, który psuje się bez żadnego widocznego objawu — warto mu raz na jakiś czas zajrzeć przez ramię.
Masz formularz, co do którego nie jesteś pewny, czy zgłoszenia docierają? Napisz do mnie — sprawdzenie całej ścieżki od formularza do skrzynki to kwestia jednego wieczoru. Stałe pilnowanie takich rzeczy wchodzi w opiekę nad stroną.
