Le tue campagne finiscono nello spam e la tua piattaforma di emailing dice che va tutto bene? È una delle situazioni più frustranti per un email marketer: il tasso di consegna mostra il 98%, l’open rate crolla e nessuno capisce perché. La causa è spesso un record SPF assente o mal configurato nella zona DNS del dominio mittente.
Un dominio senza SPF espone le sue email a due comportamenti automatici dei server di ricezione: classificazione come spam o rifiuto silenzioso a livello SMTP. Nessuno dei due errori genera un bounce visibile nella dashboard. I messaggi partono, sembrano «consegnati» ma non arrivano mai nell’inbox.
Buona notizia: aggiungere un record SPF valido richiede meno di 10 minuti. Il tempo di propagazione DNS è l’unica variabile fuori dal tuo controllo.
Cosa fa concretamente un record SPF
Il server di posta del tuo destinatario, ancora prima di esaminare il contenuto dell’email, interroga la zona DNS del tuo dominio per verificare se il server che ha inviato il messaggio è autorizzato a farlo. Questo è il ruolo dell’SPF, o Sender Policy Framework: una riga di testo nel DNS che elenca i server autorizzati a inviare a nome del tuo dominio.
Se questa riga è assente, il server di ricezione riceve una risposta vuota. Quello che fa dopo dipende dalla sua politica interna. Gmail, da novembre 2025, rifiuta attivamente le email non conformi a livello SMTP per i grandi volumi: niente più «soft penalties», è un rifiuto vero. Microsoft Exchange è ancora più severo: mostra un tasso medio di inbox placement del 75,6% per i domini parzialmente autenticati, secondo i dati TrulyInbox (analisi di 32.000+ account, maggio 2026).
Senza alcuna autenticazione, gli stessi dati mostrano un inbox placement che scende sotto il 30%. Con solo SPF, risale al 55-70%. La stack completa SPF + DKIM + DMARC raggiunge l’85-95%. Il divario tra «niente» e «tutto ben configurato» vale 60 punti percentuali.
Perché il problema rimane invisibile così a lungo
Ad aprile, un responsabile growth nota che il suo open rate è passato dal 32% al 18% in tre mesi. Nessun cambiamento sul contenuto, nessuna notifica dall’ESP. Il tasso di hard bounce era rimasto nella norma. Il suo CMO vuole una spiegazione.
Questo scenario è documentato dal rapporto Suped 2025 (Whittaker, aggiornato maggio 2026): il 43% delle aziende registra inbox misses significativi mentre le loro piattaforme mostrano tassi di consegna superiori al 95%. Il motivo sta nella distinzione tra «accepted» e «inboxed»: un’email può essere accettata dal server destinatario e finire nello spam. La dashboard vede solo il primo passaggio.
La sender reputation, però, non si degrada all’istante. Le prime settimane, Gmail è relativamente tollerante. Ma ogni invio fallito alimenta i segnali negativi: il complaint rate sale, i soft bounce si accumulano, gli utenti smettono di cliccare. Quando la reputazione IP inizia a calare in Postmaster Tools, l’SPF mancante ha spesso fatto danni per mesi.
Come verificare se il tuo SPF è assente o rotto
Tre strumenti per questa diagnostica, con approcci complementari.
- MXToolbox SPF Lookup, inserisci il tuo dominio su mxtoolbox.com, il risultato indica se esiste un record SPF e se è sintatticamente valido. Tempo: 30 secondi.
- Google Postmaster Tools, se il tuo dominio invia verso Gmail, la scheda «Authentication» mostra il tasso di email che passano SPF, DKIM e DMARC negli ultimi 30 giorni. Un tasso SPF inferiore al 95% segnala un problema attivo.
- Un invio test «intestazioni raw», invia un’email dal tuo dominio verso un indirizzo Gmail, apri il messaggio, clicca su «Mostra originale». La riga Received-SPF indica
pass,softfail,failonone.noneconferma l’assenza del record.
Se MXToolbox restituisce «No SPF Record Found» o se Postmaster Tools mostra un tasso di autenticazione SPF inferiore al 90%, prosegui con la correzione.
Creare un record SPF valido: il metodo diretto
Un record SPF è un record TXT nella tua zona DNS, con questa sintassi di base:
v=spf1 include:_spf.google.com ~all
Il meccanismo include: punta verso i server autorizzati del tuo provider di invio. Ogni ESP fornisce il proprio valore:
| Provider | Meccanismo include da aggiungere | Caso d’uso tipico |
|---|---|---|
| Google Workspace | include:_spf.google.com |
Invio tramite Gmail pro |
| Brevo (ex-Sendinblue) | include:spf.brevo.com |
Campagne marketing |
| Mailchimp / Mandrill | include:spf.mandrillapp.com |
Transactional Mandrill |
| Amazon SES | include:amazonses.com |
Invio tramite AWS |
| OVHcloud MX Plan | include:mx.ovh.com |
Hosting condiviso |
Se usi più provider, combinali in un unico record: v=spf1 include:_spf.google.com include:spf.brevo.com ~all. Attenzione al limite di 10 DNS lookup: ogni meccanismo include: consuma almeno un lookup e alcuni ne concatenano altri. Superare questo limite rompe l’autenticazione SPF anche se la sintassi è corretta.
Il valore finale ~all (softfail) o -all (fail strict) definisce cosa fanno i server con i messaggi non coperti. Per un dominio con una configurazione stabile, -all è preferibile; durante la migrazione, resta su ~all finché non hai verificato che nessuna fonte legittima sia stata dimenticata.
Aggiungere il record nel DNS: i passaggi concreti
La procedura varia leggermente a seconda del registrar o dell’hosting DNS, ma la logica è identica ovunque.
Accedi alla tua interfaccia DNS (OVHcloud, Cloudflare, Gandi, Namecheap, GoDaddy). Individua la zona DNS del tuo dominio principale. Aggiungi un nuovo record di tipo TXT, con il nome @ (o il dominio nudo a seconda dell’interfaccia) e incolla il tuo valore SPF nel campo «Valore» o «Content». Salva.
Cloudflare di solito propaga in meno di 5 minuti. OVHcloud e Gandi possono richiedere da 30 minuti ad alcune ore. Per verificare che la propagazione sia avvenuta, rilancia MXToolbox o usa dig TXT tuodominio.com da un terminale: quando il record compare, è attivo.
In pratica, la configurazione richiede 5-8 minuti su Cloudflare; il resto del tempo indicato (10 minuti) corrisponde alla diagnostica iniziale e alla verifica post-aggiunta.
L’obiezione che si sente spesso: «ho già Lemlist, Instantly, il mio ESP ci pensa lui»
Le piattaforme di outreach come Lemlist, Instantly o Smartlead configurano la propria infrastruttura di invio e possono aggiungere il loro meccanismo SPF nel tuo DNS tramite una procedura di onboarding. Ma questo meccanismo copre solo gli invii che passano per i loro server. Se il tuo dominio invia anche tramite Google Workspace, un server SMTP interno o un altro strumento transazionale, l’include del tuo ESP non li copre.
Un record SPF copre l’insieme delle fonti autorizzate per un dato dominio. L’errore classico: un dominio configurato per Lemlist, senza include per Google Workspace, che vede le sue email di fatturazione o di supporto finire nello spam perché il server Google non è nel record.
«Le SPF misconfigurations colpiscono il 15% dei domini che hanno comunque un SPF attivo.» (dmarcian, citato da TrulyInbox, maggio 2026)
In altre parole, avere un SPF non è sufficiente se la lista delle fonti autorizzate è incompleta o se superi i 10 DNS lookup.
Quello che l’SPF non risolve da solo
Un SPF correttamente configurato migliora l’autenticazione del mittente ma non firma il contenuto del messaggio. È il ruolo del DKIM, che usa una coppia di chiavi crittografiche per dimostrare che l’email non è stata modificata in transito. Senza DKIM, i dati TrulyInbox mostrano una penalità aggiuntiva di 10-15 punti di inbox placement.
DMARC, invece, sfrutta SPF e DKIM insieme per definire una policy: cosa fare se un’email fallisce entrambi i controlli? Rifiutarla, metterla in quarantena o non fare nulla (solo monitoring). Senza DMARC, anche un SPF e un DKIM corretti lasciano il tuo dominio vulnerabile allo spoofing e soprattutto non hai nessun report aggregato per rilevare le anomalie. Nel 2026, il 78% delle organizzazioni conosce DMARC ma solo il 42% lo applica davvero con una policy restrittiva (Valimail, State of DMARC 2026).
Partire dall’SPF rimane la priorità, perché è il prerequisito tecnico degli altri due. Ma un SPF da solo porta il tuo inbox rate tra il 55 e il 70%. La list hygiene e l’IP warming fanno il resto.
Gmail rifiuta ormai le email non autenticate a livello SMTP. Il record TXT nel DNS rimane l’unica variabile che controlli completamente, in pochi minuti.
