Când formularul de contact spune „Mulțumim”, dar nu sosește niciun e-mail

Imaginați-vă un mic cabinet de fizioterapie. Site-ul său are un formular de contact, iar formularul funcționează – sau cel puțin așa pare. Vizitatorii îl completează, dau clic pe „Trimite” și văd un mesaj amabil: „Vă mulțumim, vă vom răspunde în curând”. Ce nu vede nimeni: mesajele au încetat de ceva vreme să mai ajungă în căsuța poștală a cabinetului. Nu există nicio eroare, niciun mesaj returnat în căsuța nimănui, nicio lumină roșie nicăieri. Formularul eșuează în tăcere.

De ce nu observă nimeni

Pagina de „Mulțumim” a unui formular înseamnă de obicei un singur lucru: site-ul a predat mesajul mai departe. Dacă un server de e-mail îl acceptă, îl clasează ca spam sau îl respinge pe parcurs se întâmplă mai târziu, în afara câmpului vizual al formularului. Funcția mail() din PHP, de exemplu, raportează succes de îndată ce sistemul local acceptă mesajul pentru livrare – nu atunci când acesta ajunge la cineva. Așadar, vizitatorul primește o confirmare și trece mai departe. Proprietarul, între timp, vede o căsuță poștală goală și presupune că este doar o lună mai liniștită. Mai puține solicitări rareori alarmează în sine: vacanțele, vremea, economia – există întotdeauna o explicație care sună mai plauzibil decât „formularul este stricat”.

Cauzele obișnuite

• Parola SMTP sau furnizorul de e-mail s-a schimbat. Formularul continuă să se autentifice cu datele vechi, iar serverul de e-mail refuză – în tăcere, din perspectiva vizitatorului.
• PHP mail() fără autentificare. Serverul web trimite e-mailurile direct, fără a se autentifica la un server de e-mail propriu-zis. Multe servere destinatare tratează astfel de e-mailuri ca suspecte: ajung în spam sau sunt respinse direct.
• SPF, DKIM și DMARC nu se aliniază. Multe formulare pun adresa vizitatorului în câmpul From. Mesajul pretinde atunci că provine, de exemplu, de la o adresă gmail.com, dar este trimis de serverul dumneavoastră web – exact ceea ce DMARC este conceput să oprească.
• O actualizare de plugin sau o schimbare a temei strică formularul sau CAPTCHA-ul acestuia. Un șablon modificat elimină un câmp, un script nu se mai încarcă sau widgetul CAPTCHA apare fără scriptul său – iar fiecare trimitere pică validarea.
• Căsuța poștală destinatară este plină. Serverul de e-mail refuză mesajele noi, iar notificarea de returnare ajunge la o adresă pe care nu o citește nimeni.
• Bannerul de cookie-uri blochează scriptul formularului. Dacă instrumentul de consimțământ clasifică CAPTCHA-ul sau scriptul formularului drept „marketing”, vizitatorii care refuză cookie-urile pot primi un formular care nu poate fi trimis sau ale cărui trimiteri sunt respinse din cauza unui token lipsă.
• Un certificat TLS sau un domeniu expirat. Vizitatorii văd un avertisment în browser și pleacă sau serverul de e-mail nu mai poate fi accesat în siguranță. Dacă expiră domeniul căsuței poștale destinatare, e-mailurile către aceasta pur și simplu încetează.
• Un strat de cache servește pagini învechite. Un cache pentru pagini întregi poate livra un formular cu un token de securitate expirat (un nonce sau un token CSRF). Serverul respinge trimiterea și, în funcție de configurare, vizitatorul nu vede nicio eroare clară.

Capcana adresei From

A treia cauză merită o privire mai atentă, deoarece multe configurări de formulare o au încorporată implicit. DMARC verifică dacă domeniul din adresa From vizibilă corespunde unui domeniu pentru care garantează SPF sau DKIM. Dacă formularul trimite un mesaj „de la” adresa vizitatorului, serverul dumneavoastră nu este autorizat să trimită pentru acel domeniu, așa că verificarea eșuează. În funcție de politica DMARC a domeniului vizitatorului și de propriul furnizor de e-mail, mesajul ajunge în spam sau este respins. Remedierea este simplă: trimiteți de la o adresă de pe propriul domeniu și puneți adresa vizitatorului în Reply-To. Un clic pe „Răspunde” ajunge în continuare la vizitator.

Ce puteți face

1. 1Trimiteți periodic un mesaj de test prin propriul formular – cel puțin lunar și întotdeauna după actualizări, schimbări de temă sau modificări ale setărilor de e-mail. Marcați-l clar ca test, ca să nu-i răspundă nimeni.
2. 2Cunoașteți-vă ritmul normal. Dacă formularul aduce de obicei câteva mesaje pe săptămână, două săptămâni de tăcere sunt un motiv de verificare, nu o lună liniștită.
3. 3Trimiteți prin SMTP cu autentificare – prin furnizorul de e-mail sau printr-un serviciu dedicat de trimitere – în loc să vă bazați pe PHP mail().
4. 4Utilizați propriul domeniu în From și adresa vizitatorului în Reply-To. Apoi configurați SPF, DKIM și DMARC pentru acel domeniu, astfel încât mesajele să treacă de verificări.
5. 5Păstrați o copie a fiecărei trimiteri în baza de date. Multe pluginuri de formulare oferă această funcție, uneori ca supliment. Dacă e-mailul eșuează, solicitările sunt încă acolo.
6. 6Verificați formularul după fiecare actualizare de plugin – inclusiv CAPTCHA-ul și, de asemenea, cu cookie-urile refuzate.

Astfel de verificări se uită ușor, de aceea merită automatizate. Cu un cont și un domeniu verificat, formexposed poate trimite o trimitere de test marcată clar și poate verifica dacă aceasta sosește efectiv (verificarea livrării, doar cu acordul dumneavoastră). De asemenea, detectează tăcerea – un formular care primește de obicei mesaje și brusc nu mai primește niciunul – și verifică SPF, DKIM și DMARC ale e-mailurilor de notificare, precum și expirarea certificatului TLS și a domeniului. Sunteți alertat doar atunci când se schimbă ceva.

Dacă doriți doar o primă privire: o verificare gratuită pe formexposed.com nu necesită cont și nu trimite nimic. Printre altele, arată dacă un CAPTCHA este prezent, dar defect – un widget fără scriptul său, o cheie de test publică, erori în browser –, unul dintre modurile mai discrete în care un formular încetează să funcționeze. Dacă mesajele sosesc cu adevărat poate confirma doar un mesaj de test real, așa că trimiteți unul chiar astăzi.