Formularz mówi „Dziękujemy”, a wiadomość nigdy nie dociera

Wyobraź sobie mały gabinet fizjoterapii. Na jego stronie jest formularz kontaktowy i formularz działa – a przynajmniej tak to wygląda. Odwiedzający wypełniają go, klikają „Wyślij” i widzą uprzejme „Dziękujemy, wkrótce się odezwiemy”. Czego nikt nie widzi: wiadomości od jakiegoś czasu nie trafiają do skrzynki gabinetu. Nie ma błędu, nie ma zwrotki w niczyjej skrzynce, nigdzie nie zapala się czerwona lampka. Formularz psuje się po cichu.

Dlaczego nikt tego nie zauważa

Strona „Dziękujemy” po wysłaniu formularza zwykle oznacza tylko jedno: strona przekazała wiadomość dalej. Czy serwer pocztowy ją przyjmie, wrzuci do spamu, czy po drodze odrzuci – to dzieje się później i poza zasięgiem formularza. Funkcja PHP mail() zgłasza na przykład sukces, gdy tylko lokalny system przyjmie wiadomość do wysłania – a nie wtedy, gdy ktoś ją otrzyma. Odwiedzający dostaje więc potwierdzenie i idzie dalej. Właściciel widzi pustą skrzynkę i zakłada, że to po prostu spokojniejszy miesiąc. Mniej zapytań rzadko niepokoi samo w sobie: wakacje, pogoda, sytuacja gospodarcza – zawsze znajdzie się wyjaśnienie bardziej przekonujące niż „formularz nie działa”.

Najczęstsze przyczyny

• Zmieniło się hasło SMTP albo dostawca poczty. Formularz nadal loguje się starymi danymi, a serwer pocztowy odmawia – z perspektywy odwiedzającego zupełnie po cichu.
• PHP mail() bez uwierzytelniania. Serwer WWW wysyła pocztę bezpośrednio, bez logowania się do właściwego serwera pocztowego. Wiele serwerów odbiorczych traktuje takie wiadomości jako podejrzane: lądują w spamie albo są od razu odrzucane.
• SPF, DKIM i DMARC do siebie nie pasują. Wiele formularzy wstawia adres odwiedzającego w pole nadawcy (From). Wiadomość twierdzi wtedy, że pochodzi np. z adresu w gmail.com, ale wysyła ją Twój serwer WWW – a właśnie przed tym ma chronić DMARC.
• Aktualizacja wtyczki albo zmiana motywu psuje formularz lub jego CAPTCHA. Zmieniony szablon gubi pole, skrypt przestaje się ładować albo widżet CAPTCHA pojawia się bez swojego skryptu – i każde zgłoszenie odpada przy walidacji.
• Skrzynka odbiorcza jest pełna. Serwer pocztowy nie przyjmuje nowych wiadomości, a zwrotka trafia na adres, którego nikt nie czyta.
• Baner cookies blokuje skrypt formularza. Jeśli narzędzie do zarządzania zgodami zaklasyfikuje CAPTCHA albo skrypt formularza jako „marketing”, osoby odrzucające cookies mogą dostać formularz, którego nie da się wysłać – albo którego zgłoszenia są odrzucane, bo brakuje tokenu.
• Wygasły certyfikat TLS albo domena. Odwiedzający widzą ostrzeżenie przeglądarki i rezygnują albo z serwerem pocztowym nie da się już bezpiecznie połączyć. Jeśli wygaśnie domena skrzynki odbiorczej, poczta po prostu przestaje dochodzić.
• Warstwa cache serwuje nieaktualne strony. Cache całych stron może podawać formularz z wygasłym tokenem bezpieczeństwa (nonce albo token CSRF). Serwer odrzuca zgłoszenie, a zależnie od konfiguracji odwiedzający nie widzi żadnego wyraźnego błędu.

Pułapka adresu nadawcy

Trzecia przyczyna zasługuje na dokładniejsze spojrzenie, bo w wielu konfiguracjach formularzy jest wbudowana domyślnie. DMARC sprawdza, czy domena w widocznym adresie nadawcy (From) zgadza się z domeną potwierdzoną przez SPF lub DKIM. Jeśli formularz wysyła wiadomość „od” odwiedzającego, Twój serwer nie jest uprawniony do wysyłania w imieniu jego domeny, więc sprawdzenie kończy się niepowodzeniem. Zależnie od polityki DMARC domeny odwiedzającego i od Twojego dostawcy poczty wiadomość trafia do spamu albo zostaje odrzucona. Rozwiązanie jest proste: wysyłaj z adresu we własnej domenie, a adres odwiedzającego wpisz w Reply-To. Kliknięcie „Odpowiedz” i tak trafi do odwiedzającego.

Co możesz zrobić

1. 1Regularnie wysyłaj wiadomość testową przez własny formularz – co najmniej raz w miesiącu i zawsze po aktualizacjach, zmianie motywu albo ustawień poczty. Oznacz ją wyraźnie jako test, żeby nikt na nią nie odpowiadał.
2. 2Znaj swój normalny rytm. Jeśli formularz zwykle przynosi kilka wiadomości tygodniowo, dwa tygodnie ciszy to sygnał do sprawdzenia, a nie spokojny miesiąc.
3. 3Wysyłaj przez SMTP z uwierzytelnianiem – u swojego dostawcy poczty albo przez wyspecjalizowaną usługę wysyłkową – zamiast polegać na PHP mail().
4. 4W polu nadawcy (From) używaj własnej domeny, a adres odwiedzającego wpisuj w Reply-To. Następnie skonfiguruj SPF, DKIM i DMARC dla tej domeny, żeby wiadomości przechodziły weryfikację.
5. 5Zapisuj kopię każdego zgłoszenia w bazie danych. Wiele wtyczek formularzy to oferuje, czasem jako dodatek. Gdy poczta zawiedzie, zapytania nadal są na miejscu.
6. 6Po każdej aktualizacji wtyczek sprawdź formularz – razem z CAPTCHA i również przy odrzuconych cookies.

Takie sprawdzanie łatwo odkłada się na później, dlatego warto je zautomatyzować. Z kontem i zweryfikowaną domeną formexposed może wysłać wyraźnie oznaczone zgłoszenie testowe i sprawdzić, czy faktycznie dociera (test doręczenia, tylko po włączeniu). Usługa wykrywa też ciszę – formularz, który zwykle dostaje wiadomości, nagle nie dostaje żadnych – i sprawdza SPF, DKIM i DMARC maili z powiadomieniami oraz ważność certyfikatu TLS i domeny. Alert dostajesz tylko wtedy, gdy coś się zmieni.

Jeśli na początek chcesz tylko rzucić okiem: darmowe sprawdzenie na formexposed.com nie wymaga konta i niczego nie wysyła. Pokazuje między innymi, czy CAPTCHA jest obecna, ale nie działa – widżet bez skryptu, publiczny klucz testowy, błędy w przeglądarce. To jeden z cichszych sposobów, w jakie formularz przestaje działać. To, czy wiadomości naprawdę docierają, potwierdzi jednak tylko prawdziwa wiadomość testowa – więc wyślij ją jeszcze dziś.