Quan el formulari de contacte diu «Gràcies» però no arriba cap correu

Imaginem una petita consulta de fisioteràpia. El seu lloc web té un formulari de contacte, i el formulari funciona, o almenys ho sembla. Els visitants l'emplenen, fan clic a «Enviar» i veuen un amable «Gràcies, ens posarem en contacte amb vostè aviat». El que ningú no veu és que els missatges van deixar d'arribar a la safata d'entrada de la consulta fa un temps. No hi ha cap error, cap notificació de rebot a la safata d'entrada de ningú ni cap llum vermella enlloc. El formulari falla en silenci.

Per què ningú no se n'adona

La pàgina de «Gràcies» d'un formulari normalment només significa una cosa: el lloc web ha traspassat el missatge. El fet que un servidor de correu l'accepti, el classifiqui com a correu brossa o el rebutgi pel camí es determina després, fora de la vista del formulari. La funció mail() de PHP, per exemple, indica èxit tan bon punt el sistema local accepta el missatge per lliurar-lo, no quan arriba a algú. Així, el visitant rep una confirmació i continua. Mentrestant, el propietari veu una safata d'entrada buida i suposa que simplement és un mes tranquil. Una reducció de les consultes poques vegades és alarmant per si sola: les vacances, el temps, l'economia... Sempre hi ha una explicació que sembla més plausible que «el formulari no funciona».

Les causes habituals

• Ha canviat la contrasenya SMTP o el proveïdor de correu. El formulari continua iniciant sessió amb les credencials antigues i el servidor de correu ho rebutja, en silenci des del punt de vista del visitant.
• PHP mail() sense autenticació. El servidor web envia correu directament, sense iniciar sessió en un servidor de correu adequat. Molts servidors receptors consideren sospitós aquest correu: acaba a la carpeta de correu brossa o es rebutja directament.
• SPF, DKIM i DMARC no estan alineats. Molts formularis posen l'adreça del visitant al camp From. Aleshores el missatge afirma que prové, per exemple, d'una adreça gmail.com, però l'envia el seu servidor web: exactament el que DMARC està dissenyat per aturar.
• Una actualització d'un connector o un canvi de tema fa que deixi de funcionar el formulari o el seu CAPTCHA. Una plantilla modificada elimina un camp, un script ja no es carrega o el giny CAPTCHA apareix sense el seu script, i tots els enviaments fallen la validació.
• La bústia receptora és plena. El servidor de correu rebutja els missatges nous i la notificació de rebot va a una adreça que ningú no llegeix.
• El bàner de galetes bloqueja l'script del formulari. Si l'eina de consentiment classifica el CAPTCHA o l'script del formulari com a «màrqueting», els visitants que rebutgen les galetes poden trobar-se un formulari que no es pot enviar o els enviaments del qual es rebutgen perquè falta un testimoni.
• Ha caducat el certificat TLS o el domini. Els visitants veuen un avís al navegador i marxen, o ja no es pot accedir al servidor de correu de manera segura. Si caduca el domini de la bústia receptora, el correu que s'hi envia simplement deixa d'arribar.
• Una capa de memòria cau serveix pàgines obsoletes. Una memòria cau de pàgina completa pot lliurar un formulari amb un testimoni de seguretat caducat (un nonce o un testimoni CSRF). El servidor rebutja l'enviament i, segons la configuració, el visitant no veu cap error clar.

La trampa de l'adreça From

La tercera causa mereix una mirada més atenta, perquè moltes configuracions de formularis la incorporen per defecte. DMARC comprova si el domini de l'adreça From visible coincideix amb un domini avalat per SPF o DKIM. Si el formulari envia un missatge «des de» l'adreça del visitant, el seu servidor no està autoritzat a enviar per a aquell domini i la comprovació falla. Segons la política DMARC del domini del visitant i el seu proveïdor de correu, el missatge acaba a la carpeta de correu brossa o es rebutja. La solució és senzilla: enviï des d'una adreça del seu domini i posi l'adreça del visitant a Reply-To. Fer clic a «Respondre» continua permetent arribar al visitant.

Què cal fer

1. 1Enviï periòdicament un missatge de prova mitjançant el seu formulari, almenys una vegada al mes i sempre després d'actualitzacions, canvis de tema o canvis de configuració del correu. Marqui'l clarament com a prova perquè ningú no el respongui.
2. 2Conegui el seu ritme habitual. Si el formulari acostuma a aportar uns quants missatges per setmana, dues setmanes de silenci són un motiu per comprovar-lo, no pas un mes tranquil.
3. 3Enviï mitjançant SMTP amb autenticació —a través del seu proveïdor de correu o d'un servei d'enviament dedicat— en lloc de dependre de PHP mail().
4. 4Utilitzi el seu domini a From i l'adreça del visitant a Reply-To. Després configuri SPF, DKIM i DMARC per a aquell domini perquè els missatges superin les comprovacions.
5. 5Conservi una còpia de cada enviament a la base de dades. Molts connectors de formularis ho ofereixen, de vegades com a complement. Si falla el correu, les consultes continuen allà.
6. 6Comprovi el formulari després de cada actualització de connectors, inclòs el CAPTCHA i també amb les galetes rebutjades.

És fàcil oblidar aquestes comprovacions, i per això val la pena automatitzar-les. Amb un compte i un domini verificat, formexposed pot fer un enviament de prova clarament identificat i comprovar si arriba realment (la comprovació de lliurament, només amb activació expressa). També detecta el silenci —un formulari que normalment rep missatges i de sobte deixa de rebre'n— i comprova SPF, DKIM i DMARC dels correus de notificació, així com la caducitat del certificat TLS i del domini. Només rep un avís quan alguna cosa canvia.

Si només vol fer una primera ullada, una comprovació gratuïta a formexposed.com no necessita compte i no envia res. Entre altres coses, mostra si hi ha un CAPTCHA que no funciona —un giny sense el seu script, una clau de prova pública, errors al navegador—, una de les maneres més silencioses en què un formulari deixa de funcionar. Només un missatge de prova real pot confirmar que els missatges arriben; per tant, enviï'n un avui.