Il tuo modulo di contatto dice «inviato», ma non arriva niente

A chi serve questa guida

Hai un sito con un modulo di contatto o di richiesta. Un visitatore lo compila e vede un messaggio di ringraziamento, ma l’email non arriva mai nella tua casella. Oppure sospetti che succeda solo ad alcuni visitatori, perché qualcuno ti ha detto «Ti ho scritto la settimana scorsa» e tu non hai visto niente.

La guida vale per WordPress, per i costruttori di siti e per i siti scritti a mano o statici. I primi controlli non richiedono conoscenze tecniche. I passi successivi riguardano le impostazioni DNS e l’account di posta o di hosting, quindi potrebbe servirti chi si occupa del tuo dominio.

Il percorso di un messaggio e dove si perde

L’invio di un modulo attraversa più fasi, e il messaggio di ringraziamento compare di solito dopo la prima:

• Il browser invia il modulo a un gestore: un plugin, uno script sul tuo server, una funzione serverless o un servizio di moduli esterno.
• Il gestore passa il messaggio a un mittente di posta: la posta integrata del tuo server, un account SMTP o un servizio di invio email.
• Il mittente lo consegna al server di posta del destinatario, che lo accetta, lo ritarda, lo rifiuta o lo mette in quarantena.
• Il messaggio finisce in una casella: la posta in arrivo, la cartella spam o, con regole di inoltro, altrove.

La pagina di ringraziamento dimostra solo che la prima fase ha funzionato. Tutto ciò che viene dopo può fallire senza che né tu né il visitatore vediate nulla. Per questo la soluzione è controllare una fase alla volta, invece di tirare a indovinare.

Come capire quale causa è in gioco

Fai prima il test del passo 1, poi confronta quello che vedi:

• Il test finisce nello spam o nella posta indesiderata. Il server ricevente non si fida del mittente. Causa probabile: l’indirizzo del mittente o l’autenticazione email mancante. Vai ai passi 3 e 4.
• Il test non arriva mai, e il tuo servizio di invio non mostra nulla. Il gestore non l’ha mai spedito. Causa probabile: un errore che il gestore nasconde, oppure un invio disattivato. Vai al passo 2.
• Il servizio di invio mostra «bounced», «rejected» o «deferred». Leggi il motivo indicato, di solito nomina il problema. Vai ai passi 3, 4 e 7.
• Il servizio mostra «delivered», ma non trovi il messaggio. Il server ricevente lo ha accettato. Guarda spam, quarantena, regole di inoltro e indirizzo del destinatario. Vai al passo 5.
• Da te funziona, ma mancano i messaggi di alcuni visitatori. Una regola antispam del modulo blocca persone vere, oppure è stato raggiunto un limite. Vai ai passi 6 e 7.
• Ha funzionato per mesi e poi si è fermato. Qualcosa è cambiato: una chiave scaduta, una quota esaurita, nuove impostazioni DNS o un aggiornamento di plugin. Vai al passo 7.

I passi per risolvere

1. Fai una prova vera e annota l’ora. Invia tu stesso il modulo online. Come indirizzo del visitatore inserisci un indirizzo email diverso da quello che riceve i messaggi, meglio se presso un altro provider, e metti nel messaggio una parola unica, per esempio «test-1017». Annota l’ora e il tuo fuso orario, poi aspetta dieci minuti, perché alcuni server ritardano di proposito i mittenti sconosciuti. Cerca la tua parola unica nella casella di destinazione, cartella spam compresa.

2. Scopri cosa fa il gestore dopo l’invio. Apri la pagina, apri gli strumenti per sviluppatori del browser (F12), vai alla scheda Rete (Network) e invia il modulo. Clicca sulla richiesta inviata e leggi la risposta. Un «200 OK» dice solo che il gestore ha risposto. Poi cerca una traccia dall’altra parte:

   • WordPress: installa un plugin SMTP con una funzione di email di prova (per esempio WP Mail SMTP) e usa un plugin per moduli che conservi ogni invio, come Contact Form 7 con il componente Flamingo, oppure Gravity Forms. Se l’invio è salvato ma nessuna email è partita, a rompersi è la spedizione.
   • Siti statici o scritti a mano: leggi il registro della funzione o dello script che gestisce il modulo. Un errore frequente è il codice che chiama il servizio email, ignora la risposta e restituisce comunque «successo». Il gestore dovrebbe segnalare il successo solo quando il servizio email ha accettato il messaggio, altrimenti un errore.
   • Servizio di moduli esterno: accedi, guarda l’elenco degli invii e le sue note di consegna, e controlla quale indirizzo di notifica è impostato lì.

3. Spedisci dal tuo dominio e metti il visitatore in Reply-To. Molti moduli usano l’indirizzo del visitatore come mittente (From). Un messaggio che dichiara di arrivare da un indirizzo gmail.com ma parte dal tuo server non supera i controlli dei fornitori di posta (SPF, DKIM e allineamento DMARC, spiegati nelle FAQ di dmarc.org), quindi viene rifiutato o messo nello spam. Cambia il modulo in modo che il messaggio parta da un indirizzo del tuo dominio, per esempio modulo@tuodominio.com, e l’indirizzo del visitatore finisca nell’intestazione Reply-To. Puoi comunque premere «rispondi» e scrivere al visitatore.

4. Spedisci tramite un servizio autenticato e configura SPF, DKIM e DMARC. La funzione mail() di PHP, o la posta predefinita di un hosting, invia messaggi non autenticati a dovere, e molti provider li guardano con sospetto. Usa i dati SMTP del tuo fornitore di posta o di un servizio di invio email, e aggiungi i record DNS che ti chiede. Le linee guida di Google per i mittenti richiedono SPF o DKIM a ogni mittente, e SPF, DKIM e DMARC, con dominio From allineato, a chi invia grandi volumi. Un modulo di contatto spedisce poca posta, ma sono gli stessi controlli a decidere che fine fa. I record hanno questo aspetto (i valori esatti te li dà il tuo servizio):

   • SPF: un record TXT su tuodominio.com con un valore come v=spf1 include:spf.servizio-posta.example ~all
   • DKIM: un record TXT o CNAME chiamato selector1._domainkey.tuodominio.com, con il valore copiato dal tuo servizio di posta
   • DMARC: un record TXT chiamato _dmarc.tuodominio.com con il valore v=DMARC1; p=none; rua=mailto:dmarc@tuodominio.com

   Un dominio deve avere un solo record SPF, quindi unisci le voci include: in uno solo. Usa il pulsante «verifica dominio» del servizio, poi ripeti il test del passo 1. Apri il messaggio ricevuto, scegli «Mostra originale» (Gmail) o le intestazioni, e cerca spf=pass, dkim=pass e dmarc=pass.

5. Controlla dove si è fermato il messaggio. Due posti tengono una traccia:

   • Lato invio: il registro del tuo servizio di invio email o del fornitore SMTP. Ritrova il test da ora e destinatario e leggi il suo stato: accepted, delivered, deferred, bounced o complained. Un rimbalzo arriva con un motivo. La maggior parte dei servizi mostra questi stati in una dashboard, per esempio nell’elenco dei tipi di evento di Resend.
   • Lato ricezione: le cartelle spam, posta indesiderata e quarantena, le regole della casella e gli inoltri, e un errore di battitura nell’indirizzo del destinatario. Se la tua posta gira su Microsoft 365 o Google Workspace, un amministratore può avviare una traccia dei messaggi (Microsoft) o una ricerca nei registri email (Google) per vedere se il messaggio è arrivato e che fine ha fatto. Se l’indirizzo inoltra a un’altra casella, controlla anche quell’ultima casella.

6. Escludi la tua protezione antispam. Campi honeypot, CAPTCHA, limiti di frequenza, tempi minimi di compilazione e filtri di parole respingono anche persone vere. Prova il modulo da un telefono con i dati mobili e con il completamento automatico del browser attivo. Il completamento automatico può riempire un campo honeypot nascosto, e una rete mobile o un ufficio spesso condivide un solo indirizzo IP, che raggiunge prima un limite di frequenza. Un invio bloccato andrebbe salvato con il motivo, e il visitatore dovrebbe vedere un messaggio chiaro, mai un falso «inviato».

7. Controlla limiti, chiavi e modifiche recenti. I piani gratuiti dei servizi email e dei servizi di moduli hanno tetti giornalieri o mensili, oltre i quali i messaggi vengono rifiutati o scartati. Guarda la pagina di utilizzo del tuo piano (le quote di Resend ne sono un esempio). Poi chiediti cosa è cambiato quando i messaggi hanno smesso di arrivare: una chiave API scaduta o sostituita, un trasloco del sito o DNS modificati (passando a un nuovo hosting spesso si perdono i record di posta), un aggiornamento di plugin o di PHP, un indirizzo di destinatario cambiato. Segna in calendario le scadenze di chiavi e domini.

8. Rendi visibili i guasti la prossima volta. Sistemare una volta non basta, perché la stessa cosa può rompersi di nuovo senza che nessuno se ne accorga. Quattro abitudini lo evitano:

   • Tieni una copia. Salva ogni invio (database, foglio di calcolo o voci del plugin per moduli) prima di provare a spedire l’email, con uno stato come ricevuto, inviato o fallito. Così nessuna richiesta va persa, anche quando l’email si guasta. Proteggi le copie con i permessi di accesso e cancellale dopo un termine stabilito.
   • Rispondi con onestà. Mostra il messaggio di ringraziamento solo dopo che il mittente ha accettato l’email. Altrimenti mostra un errore con un altro modo per raggiungerti, per esempio il tuo indirizzo email.
   • Avvisa quando qualcosa fallisce. Fatti avvisare dal gestore quando l’invio fallisce o un limite è vicino, su un canale diverso dalla casella del modulo stesso, per esempio un messaggio in chat o un secondo indirizzo. Se il tuo servizio email offre webhook per rimbalzi e segnalazioni, usali.
   • Programma un test. Una volta al giorno o alla settimana invia un test chiaramente contrassegnato dal modulo online e verifica che sia stato salvato, accettato e consegnato. Se non arriva nei tempi previsti, fai scattare l’avviso. Basta un’attività pianificata nel tuo sistema di integrazione continua oppure un servizio di monitoraggio che sappia provare un modulo.

   Nei registri annota l’ora UTC, un identificativo dell’invio, l’identificativo del messaggio del servizio email, lo stato e l’eventuale codice di errore. Testo dei messaggi, password e chiavi non ci devono finire, come consiglia anche la guida rapida OWASP sul logging.

Quando chiedere aiuto

Coinvolgi qualcuno di esperto se:

• il test continua a mancare dopo i passi da 1 a 5, anche se il servizio dice «delivered»
• non riesci ad arrivare alle impostazioni DNS, all’account di hosting o all’amministrazione della posta, oppure non sai chi può farlo
• il modulo è codice su misura che nessuno mantiene
• i rapporti di rimbalzo o DMARC mostrano mittenti sconosciuti che usano il tuo dominio
• i messaggi persi ti costerebbero clienti o scadenze, come richieste di preventivo, prenotazioni o comunicazioni legali, e vuoi una configurazione monitorata invece di sperare