Record SPF: cos’è, come si legge e come si imposta

Il record SPF (Sender Policy Framework) è una riga nel DNS del tuo dominio con l’elenco dei server autorizzati a spedire email a suo nome. Quando un’email arriva, il server di chi riceve guarda da quale indirizzo IP è partita e controlla se quell’IP è nell’elenco. Le regole le fissa la RFC 7208, del 2014.

Il controllo qui sopra legge il tuo record, conta le ricerche DNS che costa e segnala gli errori che lo rendono inutile. Se è tutto verde, puoi fermarti qui. Se no, sotto trovi come si legge una riga che sembra scritta in codice e come si sistema senza rompere quello che già funziona.

Cosa controlla l’SPF (e cosa no)

L’SPF non guarda l’indirizzo che il destinatario vede nel campo «Da». Guarda l’indirizzo di ritorno della busta, quello a cui tornano i messaggi non consegnati (nel gergo MAIL FROM o Return-Path), più il nome con cui il server si presenta, l’HELO (RFC 7208, §2.3 e §2.4).

Di solito i due indirizzi stanno sullo stesso dominio, ma non è obbligatorio: un’email può superare l’SPF e mostrare nel «Da» un nome qualsiasi. A collegare le due cose ci pensa il DMARC, come spieghiamo nella guida al DMARC.

C’è un secondo limite. Se un cliente inoltra la tua email, il messaggio riparte da un altro server e l’SPF fallisce anche se è tutto in regola. La firma DKIM viaggia con il messaggio e regge l’inoltro: per questo si usano insieme.

Come si legge un record SPF

Questo, per esempio, potrebbe essere il record di uno studio di commercialisti con il server di posta in ufficio, un gestionale che manda gli avvisi di scadenza e la newsletter mensile su Infomail:

v=spf1 mx ip4:203.0.113.25 include:sender.infomail.it ~all

Si legge da sinistra a destra:

Pezzo	Cosa vuol dire
v=spf1	È un record SPF. Sta sempre all’inizio, scritto così
mx	Sono autorizzati i server che ricevono la posta del dominio (i suoi record MX)
ip4:203.0.113.25	È autorizzato questo indirizzo IP, il server del gestionale. Per IPv6 c’è ip6:
include:sender.infomail.it	Sono autorizzati i server elencati nell’SPF di Infomail
~all	Tutti gli altri probabilmente non sono autorizzati

Puoi incontrare anche a (l’indirizzo IP del dominio stesso), exists, raro, e ptr, che la RFC chiede di non pubblicare più (§5.5). In fondo al record possono esserci due modificatori: redirect=, che rimanda all’SPF di un altro dominio, ed exp=, una spiegazione da mostrare quando un server viene respinto.

include è il pezzo che si fraintende più spesso. Non copia il record dell’altro dominio nel tuo: chiede «questo IP passerebbe l’SPF di quel dominio?» e, se la risposta è sì, lo considera autorizzato. La RFC stessa ammette, a posteriori, che il nome è stato scelto male (§5.2).

Il finale: -all, ~all, ?all, +all

L’ultimo pezzo decide cosa succede ai server che non sono nell’elenco. Il simbolo davanti ad all si chiama qualificatore:

Finale	Risultato	Cosa succede di solito
-all	fail	Il server non è autorizzato: chi riceve può rifiutare l’email (§8.4)
~all	softfail	Probabilmente non è autorizzato: l’email non va rifiutata solo per questo, ma viene guardata con sospetto (§8.5)
?all	neutral	Il record non si pronuncia, e per chi riceve non cambia niente
+all	pass	Chiunque è autorizzato. Da non usare mai

Senza nessun all, per i server non in elenco il risultato è neutral (§4.7).

Meglio -all o ~all? La nostra opinione: comincia con ~all e passa a -all quando sei sicuro che l’elenco sia completo, cioè quando i rapporti DMARC ti hanno mostrato tutte le fonti della tua posta. Con -all e un servizio dimenticato, le email di quel servizio rischiano il rifiuto. Per Gmail e Yahoo vanno bene tutti e due.

Come si imposta un record SPF

Il record si aggiunge nel pannello DNS del dominio, dal registrar o da chi ti gestisce il sito. Prima di aprirlo, però, ti serve un elenco.

1. Scrivi chi spedisce con il tuo dominio. La casella di posta aziendale, la piattaforma per le newsletter, il gestionale che manda fatture e promemoria, il negozio online con le conferme d’ordine, il CRM. Ogni servizio ti dice cosa aggiungere: di solito un include:, a volte un indirizzo IP.
2. Guarda se un record c’è già. Il controllo in testa alla pagina te lo mostra. Se c’è, lo modifichi; non ne aggiungi un secondo.
3. Crea o modifica il record TXT. Il nome (in alcuni pannelli «host») è il dominio stesso: si scrive @ oppure si lascia vuoto, dipende dal pannello. Il valore è la riga che comincia con v=spf1.
4. Metti in fila i servizi e chiudi con un solo all. Quello che scrivi dopo all viene ignorato (§5.1).
5. Salva e rifai il controllo finché non vedi il record nuovo.

I sottodomini che spediscono, per esempio news.tuodominio.it, hanno bisogno di un record loro: quello del dominio principale non vale per loro.

Il limite delle dieci ricerche

Nei domini delle aziende che usano tanti servizi è il problema che troviamo più spesso. Ogni include, a, mx, ptr, exists e redirect costa una ricerca DNS al server che riceve, e contano anche quelle dentro gli include degli altri. Il massimo è dieci (§4.6.4): all’undicesima il controllo finisce in errore permanente e l’SPF non vale più. ip4, ip6 e all sono gratis.

A occhio non si vede. Un record con quattro include può costarne dodici, perché uno dei servizi ne ha altri dentro. Lo strumento le conta tutte e, sotto «Gli include, uno per uno», ti mostra quanto pesa ciascuno.

Per rientrare:

• togli gli include dei servizi che non usi più (il vecchio fornitore di newsletter, la prova di un CRM di due anni fa, mai disdetta nel DNS);
• togli mx e a se i server di posta sono già coperti da un include;
• solo come ultima risorsa, sostituisci un include con gli indirizzi ip4/ip6 del servizio, sapendo che andranno aggiornati a mano quando il servizio li cambia.

La stessa sezione della RFC fissa un secondo tetto: al massimo due ricerche a vuoto, cioè nomi che non esistono o non hanno record. Capita con gli include di servizi chiusi.

Quando l’SPF non funziona: gli errori tipici

Due record SPF sullo stesso dominio

Succede quando si aggiunge un servizio e il pannello crea un secondo TXT invece di modificare il primo. Con più record v=spf1 il controllo va in errore (§4.5) e nessuno dei due conta. Vanno uniti in uno, con gli include in fila e un solo all:

prima:  v=spf1 mx ~all
        v=spf1 include:sender.infomail.it ~all

dopo:   v=spf1 mx include:sender.infomail.it ~all

Il record chiuso con +all

Autorizza qualsiasi server del mondo a spedire con il tuo dominio, quindi le email false superano il controllo. Si sostituisce con ~all.

Un include che punta nel vuoto

Se il dominio incluso non ha un record SPF, per la RFC è un errore permanente (§5.2). Di solito è una lettera sbagliata nel nome o un servizio che ha cambiato indirizzo.

Il record spezzato male

Un singolo pezzo di testo in un record TXT non supera i 255 caratteri, e i record lunghi vengono divisi in più stringhe tra virgolette. Chi riceve le riunisce senza aggiungere spazi (§3.3): se il taglio cade tra due meccanismi, lo spazio va lasciato in fondo alla prima stringa, altrimenti include:a.it e include:b.it diventano una parola sola. Ancora meglio, accorcia il record.

Il meccanismo ptr

È lento, inaffidabile, e la RFC chiede di non usarlo. Si sostituisce con l’include del servizio o con i suoi indirizzi IP.

Il dominio che non spedisce, lasciato scoperto

Il dominio che usi solo per il sito, o quello vecchio che tieni per non perderlo, fa gola a chi vuole spacciarsi per te. Pubblica v=spf1 -all: dice che nessun server è autorizzato.

L’SPF con Infomail

Per Infomail ti basta un pezzo: include:sender.infomail.it. Quando aggiungi il dominio tra i Domini di invio, la piattaforma legge il record che hai già e ti propone la versione da pubblicare, con l’include inserito prima di all. Se il dominio non ha ancora un SPF, ti propone questo:

v=spf1 include:sender.infomail.it ~all

Lo copi nel pannello DNS, torni in Infomail e premi Verifica DNS. Se il DNS lo gestisce il fornitore del sito o il reparto IT, le istruzioni gliele mandi dalla pagina del dominio, e noi ti assistiamo per la configurazione del mittente se qualcosa non torna. Il percorso completo, con DKIM e DMARC, è nella guida Inserire un nuovo mittente.

Le email transazionali che il tuo gestionale manda dai nostri SMTP (smtp.infomail.ai, porta 587) escono dalla stessa infrastruttura, nell’Unione europea: l’include è lo stesso.

Cosa chiedono Gmail e Yahoo sull’SPF

Google e Yahoo chiedono a tutti i mittenti, da febbraio 2024, SPF o DKIM; a chi spedisce molto, tutti e due, insieme al DMARC. Google aggiunge che il record SPF deve comprendere tutti i servizi che spediscono per il dominio. Se Gmail rifiuta un messaggio per colpa dell’SPF, nell’errore trovi il codice 4.7.27 o 5.7.27 (domande frequenti di Google).

Chi conta come «chi spedisce molto», e cosa succede da novembre 2025 a chi non rispetta le regole, è spiegato nella guida al DMARC.

Domande frequenti

Ho già il DKIM: mi serve anche l’SPF?

Se spedisci poco, a Gmail e Yahoo basta uno dei due. Una newsletter però supera in fretta la soglia dei mittenti massivi, e lì li vogliono entrambi. E l’SPF costa una riga nel DNS.

Quanto ci mette a funzionare?

Dipende da quanto a lungo i server tengono in memoria il record vecchio. Spesso pochi minuti, a volte ore: le modifiche al DNS possono richiedere fino a 48 ore per propagarsi.

Ho superato le dieci ricerche: cosa tolgo?

Apri «Gli include, uno per uno» nella scheda SPF e guarda quanto pesa ogni servizio. Togli prima quelli che non usi più, poi mx e a se non servono. Se ancora non basta, scrivici: va fatto con calma, un servizio alla volta.

Ho tre domini che spediscono dagli stessi server. Devo scrivere tre record uguali?

Puoi scriverne uno completo sul dominio principale e, sugli altri due, solo v=spf1 redirect=tuodominio.it. Il redirect fa valere il record di quel dominio (§6.1) e, quando cambia un servizio, lo aggiorni in un posto solo. Conta come una ricerca DNS.