Le email del modulo di contatto finiscono nello spam — La soluzione: il server web come mittente (2026)

Pubblicato 2026-07-08

Dati aggiornati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Veda come assegniamo i voti.

Le email del modulo di contatto e del sito web finiscono nello spam perché il Suo server web le invia senza autenticazione — nessuna autorizzazione SPF, nessuna firma DKIM. La soluzione affidabile è instradare quella posta attraverso SMTP autenticato, non inserire il server in una lista di eccezioni. Il 46,4% dei 261.086.232 domini valutati nel censimento Defaults.Exposed (dati aggiornati al 2026-06-29) non pubblica alcun record SPF.

L’ordine degli interventi conta, e la maggior parte dei tutorial lo capovolge. Esegua una scansione gratuita per vedere cosa pubblica davvero il Suo dominio; instradi la posta del sito attraverso SMTP autenticato (il Suo provider di posta o un servizio di email transazionale) così riceve una vera firma DKIM; corregga l’indirizzo From del modulo; e solo come ultima risorsa aggiunga l’IP del server all’SPF.

Perché le email del mio sito finiscono nello spam?

Per via di chi le sta davvero inviando. Quando un visitatore compila il modulo di contatto, l’email non viene inviata dal Suo provider di posta — la genera il server web stesso, di solito tramite la funzione mail() di PHP. Dal lato di chi riceve, quel messaggio:

proviene da un IP che il Suo record SPF non autorizza (il Suo SPF copre il provider di posta, non l’hosting web);
non porta alcuna firma DKIM, quindi nulla lo lega crittograficamente al Suo dominio;
spesso parte da un IP di hosting condiviso la cui reputazione è determinata dai siti di centinaia di sconosciuti.

Posta non autenticata da un IP con reputazione mista è esattamente ciò che i filtri antispam esistono per intercettare — Gmail e Outlook vedono un server qualsiasi che afferma di essere Lei. Il quadro generale è desolante: il 46,4% dei domini non pubblica alcun SPF, e solo il 10,59% (27.640.987 su 261.086.232 domini valutati, censimento aggiornato al 2026-06-29) applica una politica DMARC.

Perché colpisce in particolare i siti WordPress?

WordPress invia tutta la sua posta — notifiche dei moduli, reset delle password, conferme d’ordine — attraverso una sola funzione, wp_mail(), che di default si appoggia alla mail() di PHP sul server web. Ogni sito WordPress che non è stato riconfigurato di proposito è, fin dall’installazione, un mittente non autenticato. I plugin per moduli (Contact Form 7, WPForms, Gravity Forms) consegnano tutti la posta alla stessa funzione: sembra un problema del plugin ma è un problema di trasporto.

La soluzione non è un altro plugin per moduli ma un plugin SMTP (WP Mail SMTP e i suoi equivalenti), che reinstrada tutto ciò che wp_mail() invia attraverso un vero account di posta autenticato — infrastruttura che il Suo SPF già autorizza, con una firma DKIM allegata.

Quale metodo di invio dovrebbe usare il sito?

Metodo di invio	SPF	DKIM	Sopravvive a una migrazione di hosting?	Verdetto
`mail()` di PHP / `wp_mail()` di default dal server web	fallisce	nessuna	n/d — non funziona ovunque	il problema, non un’opzione
SMTP autenticato tramite il Suo provider di posta (Google Workspace, Microsoft 365, ecc.)	passa	firmato	sì — indipendente dall’hosting	la soluzione per la maggior parte dei siti
Servizio di email transazionale (SES, Postmark, Brevo, ecc.) con il Suo dominio verificato	passa	firmato	sì	la soluzione ad alti volumi (e-commerce, moduli grandi)
IP del server web aggiunto al Suo record SPF	passa (solo SPF)	nessuna	no — si rompe in silenzio quando l’IP cambia	solo come ripiego — veda sotto

Per poche notifiche al giorno, l’SMTP attraverso la casella che già paga è la via più breve; a volumi reali, un servizio transazionale è fatto apposta. Entrambi Le danno DKIM — la scorciatoia dell’IP in whitelist non lo fa mai.

Come sistemo la consegna delle email del modulo di contatto?

Esegua la scansione gratuita su defaults.exposed prima di toccare qualsiasi cosa. Mostra quali SPF, DKIM e DMARC il Suo dominio pubblica davvero — se sta correggendo il trasporto del modulo, un record mancante, o entrambi. Nessun SPF? Parta da come sistemare l’SPF.
Crei un’identità SMTP dedicata per il sito — ad es. [email protected] presso il Suo provider di posta, oppure un dominio di invio verificato in un servizio transazionale. Usi una password per app o una chiave API revocabile, non la password della casella di una persona.
Instradi la posta del sito attraverso quell’identità. WordPress: installi un plugin SMTP e lo punti su quell’account. Altri stack: configuri il mailer del framework al posto della mail() locale.
Corregga l’indirizzo From (l’anti-pattern qui sotto): il From deve essere il Suo dominio; il visitatore va in Reply-To.
Se il mittente è un servizio transazionale, aggiunga i suoi record DKIM (di solito una coppia di CNAME) così la posta viene firmata con il Suo dominio — i passaggi DNS ricalcano le guide di configurazione SPF.
Invii un test dal modulo e riesegua la scansione. Le intestazioni devono mostrare spf=pass e dkim=pass per il Suo dominio; poi risolva il resto che la scansione segnala tramite sistemare SPF e sistemare DKIM.

Perché il modulo invia “da” l’indirizzo email del visitatore?

È la ferita autoinflitta più comune nella configurazione dei moduli, e molti plugin un tempo lo facevano di default: la notifica arriva From: l’indirizzo del visitatore, così basta premere Rispondi. Sembra comodo, ed è falsificazione. Il Suo server non ha alcun diritto di inviare posta come [email protected] — fallisce SPF e DKIM per gmail.com, e la politica DMARC di Gmail dice ai destinatari di cestinarla o respingerla. La correzione non costa nulla:

From: un indirizzo del Suo dominio (l’identità SMTP del passo 2)
Reply-To: l’indirizzo del visitatore — la risposta arriva comunque direttamente a lui

Ogni plugin per moduli diffuso lo supporta; sono due campi nelle impostazioni delle notifiche.

Perché non aggiungere semplicemente l’IP del server al mio record SPF?

È la soluzione a cui la maggior parte delle discussioni nei forum arriva per prima, ed è il ripiego per una ragione. Aggiungere ip4:<server> (o un meccanismo a per il Suo hosting web) all’SPF fa effettivamente passare il controllo grezzo — ma:

Su hosting condiviso autorizza degli sconosciuti. L’IP appartiene alla macchina, non a Lei; ogni altro sito su quel server può ora inviare posta che passa l’SPF a nome del Suo dominio.
Si rompe in silenzio. Gli hosting migrano i server e ruotano gli IP senza avvisarLa; il Suo SPF continua ad autorizzare un indirizzo che ha lasciato mesi fa.
Non Le dà DKIM. L’SPF da solo si rompe con l’inoltro e non può portarLa verso l’applicazione di DMARC come può farlo una firma.

Riservi questa strada al caso davvero vincolato: un server dedicato con un IP statico sotto il Suo controllo e un’applicazione che non sa parlare SMTP — e, se può, la abbini alla firma DKIM sulla macchina.

L’SPF controlla davvero l’indirizzo che il mio modulo mette nel “From”?

No — e questo fa inciampare metà delle diagnosi fai-da-te. I destinatari valutano l’SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’intestazione From. I server web spesso stampano il proprio hostname nel Return-Path, quindi il Suo record SPF non è mai stato nemmeno consultato — il destinatario ha controllato l’SPF di srv0421.examplehost.com. L’SMTP autenticato risolve anche questo: il Return-Path diventa il Suo dominio, così il pass SPF finalmente conta per Lei. È anche il motivo per cui DKIM è importante — l’allineamento DMARC richiede un pass legato al dominio nel From, e una firma DKIM viaggia insieme al messaggio.

Domande frequenti

Un plugin SMTP sistemerà anche le email di reset password e di WooCommerce? Sì. Su WordPress tutto passa da wp_mail(), quindi reinstradarla sistema in un colpo solo le notifiche dei moduli, i reset delle password e le email d’ordine.

Mi servono comunque i record SPF e DKIM se uso un plugin SMTP? Sì — il plugin cambia quale infrastruttura invia la Sua posta; i record sono ciò che la autorizza. Se il Suo dominio è tra il 46,4% dei 261.086.232 domini valutati senza record SPF (censimento, 2026-06-29), l’SMTP autenticato da solo non La salverà. La checklist email per un dominio nuovo copre l’insieme completo dei record.

Le email del mio modulo passano l’SPF ma falliscono comunque DMARC — perché? Quasi sempre è l’anti-pattern del From falsificato descritto sopra, oppure l’SPF che passa per il dominio Return-Path dell’hosting invece che per il Suo. Corregga prima From/Reply-To; se fallisce ancora, il pezzo mancante è una firma DKIM allineata — veda “DKIM signature not valid”. Se falliscono anche strumenti SaaS oltre al sito, la guida all’SPF che fallisce per i SaaS copre l’ordine di intervento.

Vale la pena fare tutto questo per un modulo di contatto con poco traffico? Il modulo è di solito il punto da cui entrano i soldi — una richiesta persa è un cliente che non ha mai saputo di aver perso. E la correzione è gratuita; l’ostacolo è sapere che il mittente non autenticato è sempre stato il server web.

Invii il report al titolare

Se è lo sviluppatore o il consulente che sta sistemando il problema: quando l’invio di test passa, riesegua la scansione gratuita e inoltri il report con il voto al titolare del sito — una registrazione datata e in linguaggio semplice che il dominio si autentica correttamente, e il documento che gli servirà per il prossimo rinnovo dell’assicurazione cyber o per il questionario di sicurezza di un cliente. Se è il titolare e sta leggendo perché le richieste hanno smesso di arrivare: mandi questa pagina e il Suo report di scansione a chi gestisce il Suo sito — un lavoro di un pomeriggio, con un prima-e-dopo da mostrarLe.

Controlli il Suo dominio → · L’SPF fallisce per i Suoi strumenti SaaS? → · Sistemare l’SPF → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati e trattati nell’UE.