Se il modulo contatti del tuo sito mostra “messaggio inviato” ma nella casella non arriva niente, nella grande maggioranza dei casi il problema non è il form: è il modo in cui il sito spedisce le email. WordPress usa la funzione mail() di PHP, che invia senza autenticazione. Gmail, Outlook e Aruba trattano quei messaggi come sospetti e li scartano prima ancora della cartella spam.
La buona notizia è che si diagnostica in dieci minuti. La cattiva è che, mentre lo fai, non sai quante richieste hai già perso — e non c’è modo di recuperarle.
Se stai perdendo richieste in questo momento, scrivici su WhatsApp: guardiamo il tuo form e ti diciamo dov’è il problema. scrivici ora su WhatsApp
1. Il sito spedisce con PHP mail() invece che via SMTP
È la causa numero uno, e da sola spiega più della metà dei casi che ci arrivano.
mail() consegna il messaggio direttamente dal server web, senza credenziali e senza che nessuno garantisca chi sia il mittente. Per i grandi provider di posta è esattamente il profilo di un messaggio automatico non autorizzato: viene rifiutato in silenzio, quindi nel sito non compare alcun errore.
La soluzione è far spedire WordPress tramite SMTP autenticato, con le stesse credenziali della tua casella. Il messaggio parte dal server di posta, con le sue autorizzazioni, e viene accettato normalmente.
Sui siti che gestiamo configuriamo Easy WP SMTP o FluentSMTP, collegati a una casella dedicata del dominio. Sono due strumenti solidi e leggeri: l’importante non è quale dei due, ma che la spedizione passi da credenziali reali e non dal server web.
Attenzione a una trappola che vediamo spesso. Un nostro cliente di Roma ha cambiato la password della casella di posta, come è giusto fare ogni tanto, ma non l’ha aggiornata nella configurazione SMTP del sito. Da quel momento i moduli hanno continuato a mostrare “messaggio inviato” e nessuna richiesta è più arrivata. Nessun avviso, nessun errore: solo il silenzio.
Se cambi la password della posta, aggiornala anche nel sito. È una riga da mettere in agenda insieme al cambio password, non un dettaglio tecnico.
2. Il form spedisce usando l’indirizzo del visitatore come mittente
Molti moduli sono configurati con il campo “Da” impostato sull’email di chi compila. Sembra comodo — rispondi direttamente — ma tecnicamente è il tuo server che dichiara di essere gmail.com, e i controlli SPF e DMARC di Gmail lo bloccano.
La configurazione corretta è una sola:
- Da (From): un indirizzo del tuo dominio, per esempio
noreply@tuodominio.it - Rispondi a (Reply-To): l’email del visitatore
Così il messaggio è legittimo e tu puoi comunque rispondere con un clic.
3. SPF, DKIM e DMARC assenti o sbagliati
Sono tre record DNS che dicono ai provider di posta quali server sono autorizzati a spedire per conto del tuo dominio. Se mancano, o se ne è rimasto uno vecchio dopo un cambio di hosting, le email partono ma vengono declassate o rifiutate.
Il sintomo tipico: le email arrivano ad alcuni destinatari e ad altri no. Se il modulo funziona quando fai la prova sulla tua casella aziendale ma non su Gmail, guarda qui.
4. Il sito consegna la posta a sé stesso invece che al tuo provider
Succede quando la posta è su Google Workspace, Microsoft 365 o Aruba, ma il sito è ospitato altrove. Il server web, vedendo un indirizzo del proprio dominio, prova a consegnare nella casella locale — che nessuno legge mai — invece di seguire i record MX verso il provider vero.
Il messaggio risulta “inviato con successo” e finisce in una casella fantasma sul server. È una delle cause più difficili da individuare da soli, perché nessun log segnala un errore.
5. reCAPTCHA scaduto o chiavi non più valide
Se il sito ha cambiato dominio, o se le chiavi sono state generate su un account Google a cui non hai più accesso, la verifica fallisce silenziosamente: il form si comporta come se avesse inviato, ma il messaggio viene scartato prima della spedizione.
Stessa cosa con il passaggio da reCAPTCHA v2 a v3 senza aggiornare la configurazione del plugin.
Come verificarlo: apri il sito, premi F12, vai su Console e invia il modulo. Se compare un errore che nomina recaptcha o grecaptcha, hai trovato la causa.
6. Filtri antispam troppo aggressivi
Alcuni plugin antispam scartano i messaggi senza avvisare nessuno. Le regole più comuni che generano falsi positivi sono il blocco dei messaggi contenenti link, quello dei messaggi troppo brevi e i filtri geografici che escludono interi paesi.
Il risultato è che perdi proprio le richieste sintetiche, quelle di chi scrive “buongiorno, potete chiamarmi?” — cioè spesso i contatti migliori.
Il punto critico è che questi filtri scartano senza lasciare traccia: non trovi nulla in posta indesiderata, perché il messaggio non è mai stato consegnato. Se il modulo salva anche nel database, te ne accorgi confrontando i due elenchi; altrimenti non lo scopri mai.
7. Nessuno ha mai controllato che funzionasse
La causa più banale e la più frequente in assoluto: il modulo è stato provato una volta il giorno del lancio, poi mai più. Nel frattempo il sito ha cambiato hosting, WordPress si è aggiornato, la casella è cambiata.
Un modulo contatti non è un elemento grafico: è un impianto, e come tutti gli impianti va verificato periodicamente.
La regola che risolve il problema alla radice
Non far dipendere le tue richieste solo dall’email. Usa un plugin per i moduli che, oltre a spedire, salvi ogni messaggio nel database del sito. È una funzione che tutti i principali plugin di contact form offrono, ma che quasi nessuno attiva.
Così, qualunque cosa succeda alla posta, il messaggio resta. E quando un cliente ti dice “vi avevo scritto e non mi avete risposto”, puoi verificarlo invece di scusarti.
È la prima cosa che impostiamo sui siti che prendiamo in gestione.
Come capire in dieci minuti dove si è rotto
- Invia una prova dal modulo e controlla se il sito registra l’invio. Se non c’è alcun log, installane uno: senza log stai indovinando
- Ripeti la prova con tre destinatari diversi — una casella aziendale, una Gmail, una Outlook. Se ne arriva una sola, il problema è nell’autenticazione del dominio
- Verifica i record del dominio con uno strumento di controllo della deliverabilità: ti dice subito se SPF e DKIM sono a posto
- Controlla la console del browser durante l’invio, per escludere reCAPTCHA e conflitti JavaScript
- Guarda la posta indesiderata dei destinatari, ma soprattutto le regole del server: alcuni filtri lavorano prima che il messaggio arrivi alla casella
Se al passaggio 3 qualcosa non torna, ti serve accesso al DNS del dominio — e qui molte aziende scoprono di non sapere chi lo gestisce.
Domande frequenti
Il form dice “inviato con successo”, quindi funziona? No. Quel messaggio conferma soltanto che il modulo ha completato la sua parte. La consegna avviene dopo, e può fallire senza che il sito lo sappia.
Perché le email arrivavano e adesso no? Nella maggior parte dei casi c’è stato un cambio: hosting, provider di posta, aggiornamento di WordPress o del plugin. Se sai indicare la settimana in cui è successo, la diagnosi si accorcia molto.
Posso recuperare le richieste che ho perso? Se il modulo salvava i messaggi nel database, sì. Se si affidava solo all’email, no: non esiste una copia da nessuna parte. È il motivo per cui vale la pena sistemare la cosa prima che ricapiti.
Quanto costa risolverlo? Nella maggior parte dei casi tra 80 e 150 euro più IVA, a seconda di quanto è complessa la situazione del dominio. L’intervento comprende la configurazione della spedizione SMTP, la verifica dell’autenticazione del dominio, il salvataggio delle richieste nel database e una prova di consegna su più provider. Se durante l’analisi emerge che il problema è altrove, te lo diciamo prima di iniziare.
Se preferisci non occupartene
Configurazione della spedizione, autenticazione del dominio, salvataggio delle richieste e controllo periodico fanno parte del nostro servizio di manutenzione: il modulo viene verificato a ogni intervento, non solo il giorno del lancio.
Assistenza e manutenzione siti web — ADS Network, dal 2005.