Quando il modulo di contatto dice “Grazie” ma non arriva nessuna e-mail

Immagini un piccolo studio di fisioterapia. Il suo sito web ha un modulo di contatto, e il modulo funziona – o almeno così sembra. I visitatori lo compilano, cliccano su “Invia” e vedono un cortese “Grazie, La ricontatteremo al più presto”. Ciò che nessuno vede: da tempo i messaggi non arrivano più nella casella di posta dello studio. Nessun errore, nessun messaggio di mancato recapito nella casella di nessuno, nessuna spia rossa da nessuna parte. Il modulo fallisce in silenzio.

Perché nessuno se ne accorge

La pagina “Grazie” di un modulo di solito significa una sola cosa: il sito web ha passato il messaggio. Se un server di posta lo accetti, lo archivi come spam o lo rifiuti lungo il percorso avviene dopo, fuori dalla vista del modulo. La funzione mail() di PHP, ad esempio, segnala il successo non appena il sistema locale accetta il messaggio per il recapito – non quando raggiunge qualcuno. Così il visitatore riceve una conferma e va avanti. Il titolare, nel frattempo, vede una casella di posta vuota e pensa che sia solo un mese tranquillo. Un calo delle richieste raramente allarma di per sé: le ferie, il meteo, la congiuntura – c’è sempre una spiegazione che suona più plausibile di “il modulo è rotto”.

Le cause abituali

• La password SMTP o il provider di posta sono cambiati. Il modulo continua ad accedere con le vecchie credenziali e il server di posta rifiuta – in silenzio, per quanto il visitatore possa vedere.
• PHP mail() senza autenticazione. Il server web invia la posta direttamente, senza accedere a un vero server di posta. Molti server riceventi considerano sospetta tale posta: finisce nello spam o viene rifiutata del tutto.
• SPF, DKIM e DMARC non sono allineati. Molti moduli inseriscono l’indirizzo del visitatore nel campo From. Il messaggio dichiara allora di provenire, ad esempio, da un indirizzo gmail.com, ma viene inviato dal Suo server web – esattamente ciò che DMARC è progettato per impedire.
• Un aggiornamento di un plugin o un cambio di tema guasta il modulo o il suo CAPTCHA. Un template modificato elimina un campo, uno script non si carica più, o il widget CAPTCHA compare senza il suo script – e ogni invio non supera la validazione.
• La casella di posta ricevente è piena. Il server di posta rifiuta i nuovi messaggi, e il messaggio di mancato recapito va a un indirizzo che nessuno legge.
• Il banner dei cookie blocca lo script del modulo. Se lo strumento di consenso classifica il CAPTCHA o lo script del modulo come “marketing”, i visitatori che rifiutano i cookie possono ritrovarsi con un modulo che non può essere inviato, o i cui invii vengono respinti perché manca un token.
• Un certificato TLS o un dominio scaduto. I visitatori vedono un avviso del browser e se ne vanno, oppure il server di posta non è più raggiungibile in modo sicuro. Se scade il dominio della casella di posta ricevente, la posta indirizzata a essa semplicemente si ferma.
• Un livello di caching serve pagine obsolete. Una cache a pagina intera può fornire un modulo con un token di sicurezza scaduto (un nonce o un token CSRF). Il server respinge l’invio e, a seconda della configurazione, il visitatore non vede alcun errore chiaro.

La trappola dell’indirizzo From

La terza causa merita un esame più attento, perché molte configurazioni dei moduli la includono per impostazione predefinita. DMARC verifica se il dominio dell’indirizzo From visibile corrisponde a un dominio garantito da SPF o DKIM. Se il modulo invia un messaggio “da” l’indirizzo del visitatore, il Suo server non è autorizzato a inviare per quel dominio, quindi il controllo fallisce. A seconda della policy DMARC del dominio del visitatore e del Suo provider di posta, il messaggio finisce nello spam o viene rifiutato. La soluzione è semplice: inviare da un indirizzo del proprio dominio e inserire l’indirizzo del visitatore in Reply-To. Cliccando su “Rispondi” si raggiunge comunque il visitatore.

Che cosa fare

1. 1Invii regolarmente un messaggio di prova tramite il Suo modulo – almeno una volta al mese, e sempre dopo aggiornamenti, cambi di tema o modifiche alle impostazioni di posta. Lo contrassegni chiaramente come test, così che nessuno vi risponda.
2. 2Conosca il Suo ritmo normale. Se il modulo porta di solito qualche messaggio a settimana, due settimane di silenzio sono un motivo per controllare, non un mese tranquillo.
3. 3Invii tramite SMTP con autenticazione – attraverso il Suo provider di posta o un servizio di invio dedicato – invece di affidarsi a PHP mail().
4. 4Utilizzi il proprio dominio in From e l’indirizzo del visitatore in Reply-To. Poi configuri SPF, DKIM e DMARC per quel dominio, affinché i messaggi superino i controlli.
5. 5Conservi una copia di ogni invio nel database. Molti plugin per moduli lo offrono, a volte come componente aggiuntivo. Se la posta non funziona, le richieste ci sono ancora.
6. 6Controlli il modulo dopo ogni aggiornamento di un plugin – compreso il CAPTCHA, e anche con i cookie rifiutati.

Controlli come questi si dimenticano facilmente, ed è per questo che conviene automatizzarli. Con un account e un dominio verificato, formexposed può inviare un invio di prova chiaramente contrassegnato e verificare se arriva davvero (il controllo del recapito, solo su attivazione). Rileva inoltre il silenzio – un modulo che di norma riceve messaggi e improvvisamente non ne riceve più – e controlla SPF, DKIM e DMARC delle e-mail di notifica, nonché la scadenza del certificato TLS e del dominio. Riceve un avviso solo quando qualcosa cambia.

Se desidera solo un primo sguardo: una verifica gratuita su formexposed.com non richiede alcun account e non invia nulla. Tra l’altro, mostra se un CAPTCHA è presente ma non funzionante – un widget senza il suo script, una chiave di test pubblica, errori nel browser – uno dei modi più silenziosi in cui un modulo smette di funzionare. Che i messaggi arrivino davvero può confermarlo solo un vero messaggio di prova, quindi ne invii uno oggi stesso.