← Tutti gli articoli
Deliverability20/10/20268 min di letturaRedazione Liberatori

Record SPF: come scriverlo, gli errori tipici e come verificarlo

Una riga di testo nel DNS decide se le tue email arrivano o vengono guardate con sospetto. Ecco come scrivere il record SPF, dove si sbaglia e come controllarlo davvero.

Record SPF: come scriverlo, gli errori tipici e come verificarlo

Cos'è un record SPF e cosa controlla davvero

Un record SPF è una riga di testo nel DNS del tuo dominio che elenca i server autorizzati a spedire email a nome di quel dominio. Chi riceve confronta l'indirizzo IP del server che gli sta consegnando il messaggio con quell'elenco: se c'è, SPF passa; se non c'è, il messaggio perde credibilità o viene scartato.

Un dettaglio che spiega molti equivoci: SPF non guarda il mittente che vedi nel programma di posta. Controlla il dominio dell'envelope sender, quello che compare nell'intestazione Return-Path. Di solito i due coincidono, ma se spedisci tramite una piattaforma esterna possono essere diversi, e allora il controllo avviene sul dominio della piattaforma, non sul tuo. È uno dei motivi per cui SPF da solo non basta e va letto insieme a DKIM e DMARC. Per la visione d'insieme trovi SPF, DKIM e DMARC: cosa fanno e in che ordine configurarli in un articolo dedicato.

Come creare un record SPF, passo per passo

Scriverlo è rapido. Il tempo vero se ne va nel capire chi spedisce email a nome tuo, perché è lì che ci si dimentica sempre qualcosa.

  1. Elenca tutto ciò che spedisce. La posta aziendale (Google Workspace o Microsoft 365), il gestionale che invia le fatture, il modulo del sito, lo strumento per le newsletter, la piattaforma per le cold email. Chiedi a chi amministra ciascun sistema: non fidarti della memoria.
  2. Per ognuno, trova cosa va dichiarato. I fornitori seri pubblicano la stringa da inserire, quasi sempre un include. Se invece spedisci da un server tuo con indirizzo fisso, usi ip4 seguito dall'indirizzo.
  3. Componi una sola riga, che inizia con v=spf1 e finisce con una regola di chiusura.
  4. Pubblicala come record TXT sulla radice del dominio (nel pannello DNS spesso si indica con @).
  5. Verifica, come spiego più sotto, prima di considerare chiuso il lavoro.

Un esempio per un'azienda che usa Google Workspace e un servizio esterno per le newsletter:

v=spf1 include:_spf.google.com include:spf.servizio-newsletter.example ip4:203.0.113.25 ~all

Si legge da sinistra a destra. Dichiari la versione, poi autorizzi i server di Google, quelli del servizio newsletter e un indirizzo fisso. Infine dici cosa fare con tutto il resto. Indirizzi e nomi qui sono di esempio: sostituiscili con quelli reali dei tuoi fornitori.

I pezzi che userai quasi sempre

  • include: rimanda al record SPF di un fornitore. Comodo, ma ogni include ha un costo, come vedremo.
  • ip4: e ip6: autorizzano un indirizzo o un intervallo. Non richiedono interrogazioni DNS aggiuntive.
  • a e mx autorizzano i server a cui puntano il nome del dominio e la posta in arrivo. Servono raramente, e contano nel limite.
  • all chiude il record e stabilisce cosa succede a chi non è elencato.

Gli errori tipici: più record, troppi include

Quasi tutti i record SPF rotti sbagliano in uno di questi modi. Nessuno dà un errore visibile quando lo pubblichi: il pannello DNS accetta tutto, e il guaio emerge settimane dopo, quando qualcuno nota che le email finiscono in spam.

Due record SPF sullo stesso dominio

Succede così: anni fa qualcuno ha configurato la posta e ha messo un record. Oggi il responsabile marketing attiva uno strumento di invio, legge la guida del fornitore, che dice «aggiungi questo record TXT», e ne crea un secondo. Ora il dominio ha due righe che iniziano con v=spf1.

Chi riceve non ne sceglie una: se ne trova due, restituisce un errore permanente (permerror) e SPF fallisce per tutti, anche per i server legittimi. La regola è semplice: un dominio, un solo record SPF. Quando serve un nuovo servizio, aggiungi il suo include dentro la riga esistente, non una riga nuova.

Più di dieci interrogazioni DNS

Qui il limite è nel protocollo: per valutare un record, chi riceve può fare al massimo dieci interrogazioni DNS. Contano include, a, mx, exists, redirect (e il vecchio ptr). Non contano ip4, ip6 e all.

Il punto che frega tutti: i fornitori a loro volta usano include dentro i loro record, e le interrogazioni annidate si sommano alle tue. Ne aggiungi uno e ne consumi più di uno. Con la posta, due piattaforme di invio, il CRM e il servizio di fatturazione il limite si supera senza accorgersene, e da quel momento il controllo fallisce con lo stesso permerror dei record doppi.

Cosa fare, in ordine di preferenza:

  1. Togli i servizi che non spediscono più. Succede più spesso di quanto si pensi: strumenti di prova abbandonati che restano nel record per anni.
  2. Sposta alcuni invii su un sottodominio con il suo record, così il limite si applica a ciascun record separatamente.
  3. Sostituisci un include con gli ip4 corrispondenti solo se il fornitore garantisce indirizzi stabili. Se cambiano senza avviso, il tuo record diventa sbagliato in silenzio.

Per lo stesso motivo sconsigliamo gli strumenti che «appiattiscono» automaticamente il record sostituendo gli include con indirizzi: funzionano finché il fornitore non cambia server, e poi nessuno se ne accorge.

Altri errori che si vedono spesso

  • Il meccanismo ptr. È sconsigliato dalle specifiche, lento e inutile: toglilo.
  • Il +all in fondo. Significa «chiunque può spedire per me». Equivale a non avere SPF.
  • Il record scritto sul sottodominio sbagliato. SPF non si eredita: mail.tuodominio.it non usa il record di tuodominio.it.
  • Virgolette e spazi copiati male da una pagina web o da un PDF. I caratteri tipografici al posto delle virgolette normali rompono la riga.

~all o -all: quale chiusura scegliere

La differenza è questa. Con -all (fail) dichiari che chi non è elencato non è autorizzato e va respinto. Con ~all (softfail) dici che non è autorizzato ma di non essere drastici. Il ?all è neutro e non serve a niente.

La nostra posizione: parti con ~all, controlla per un paio di settimane che ogni sistema legittimo passi, e passa a -all solo quando hai la certezza di aver elencato tutto. Metterlo subito è il modo più rapido per scoprire, da una telefonata del titolare, che le fatture non partono più. Quando poi attivi DMARC, la distinzione conta meno, perché è la politica DMARC a indicare cosa fare di un messaggio che fallisce; ne parliamo in Record DMARC: cos'è, le tre politiche e come leggere i rapporti.

Come verificare un record SPF

Due controlli, entrambi gratuiti, e il secondo è quello che conta.

Il record pubblicato. Da terminale:

dig +short TXT tuodominio.it

Tra le righe TXT devi trovarne una sola che inizia con v=spf1. Se ne vedi due, hai trovato il problema. Per contare le interrogazioni apri uno a uno gli include e somma: esistono verificatori online che lo fanno e segnalano il superamento del limite, ma conviene capire il conteggio una volta a mano, per non dipendere da uno strumento.

Il messaggio reale. Spedisci un'email vera, dallo strumento vero, a una casella Gmail tua. Apri il messaggio, scegli «Mostra originale» e cerca la riga Authentication-Results. Deve contenere spf=pass e, accanto, il dominio che ti aspetti. Fallo per ogni sistema che spedisce: posta, gestionale, newsletter, piattaforma di cold email. Il record può essere perfetto e non coprire comunque il quinto strumento, quello di cui si era dimenticato tutto il reparto.

Se compare spf=softfail o spf=fail per un servizio che dovrebbe essere autorizzato, di solito manca il suo include (oppure il dominio controllato è quello della piattaforma, come visto all'inizio). Se compare permerror, torna ai due errori sopra.

Un record per ogni dominio che spedisce, anche quelli a freddo

SPF vale per il singolo dominio: ogni dominio o sottodominio da cui parte posta ha il suo record. Per le campagne a freddo usiamo domini dedicati e più caselle, mai il dominio principale dell'azienda: così un problema di reputazione non tocca la posta dei commerciali e dell'amministrazione. Su quei domini il record è cortissimo e il limite delle interrogazioni non si pone mai.

Vale anche per i domini che non spediscono nulla, come i vecchi nomi dell'azienda o le varianti registrate per prudenza. Un record v=spf1 -all dice che da lì non parte posta legittima, e toglie spazio a chi volesse spacciarsi per te.

Dopo ogni modifica tieni d'occhio i rimbalzi per qualche giorno. Se salgono, capire se la causa è la configurazione o altro è il tema di hard bounce e soft bounce.

Apri il pannello DNS del tuo dominio principale, conta le righe TXT che iniziano con v=spf1 e, se sono più di una, uniscile in una sola prima di toccare qualsiasi altra cosa.

Domande frequenti

Quanti record SPF può avere un dominio?

Uno solo. Se ne pubblichi due, chi riceve restituisce un errore permanente (permerror) e SPF fallisce anche per i server legittimi. Per aggiungere un servizio, inserisci il suo include nella riga già esistente.

Quanti include si possono mettere in un record SPF?

Il limite non è sugli include in sé, ma sulle interrogazioni DNS: al massimo dieci, comprese quelle che nascono dagli include dei fornitori. Superato il limite, il controllo fallisce con permerror.

Come controllo se il mio record SPF funziona?

Con il comando dig +short TXT sul tuo dominio vedi il record pubblicato, che deve essere uno solo. Poi spedisci un'email reale a una casella Gmail e cerca nell'originale la riga Authentication-Results: deve riportare spf=pass.

Continua la lettura