Record SPF: cos'è e come configurarlo, con esempi

Punti chiave

Il record SPF è un record DNS di tipo TXT, pubblicato sul dominio, che elenca i server autorizzati a spedire email a suo nome: comincia con v=spf1, elenca le fonti con meccanismi come include e ip4 e chiude con all.
Per Google Workspace il record indicato da Google è v=spf1 include:_spf.google.com ~all; per Microsoft 365 quello indicato da Microsoft è v=spf1 include:spf.protection.outlook.com -all.
Ogni dominio può avere un solo record SPF: due record producono un permerror. Ogni sottodominio che spedisce ha bisogno di un record proprio.
La RFC 7208 ammette al massimo 10 termini che richiedono ricerche DNS (include, a, mx, ptr, exists, redirect), contando anche quelle dei record inclusi: oltre il limite il controllo dà permerror.
Google consiglia ~all, Microsoft -all: la scelta dipende da quanto è completo l'inventario dei mittenti e da DKIM e DMARC, perché è la policy DMARC a decidere cosa fare dei messaggi che falliscono.
SPF controlla il dominio della busta (MAIL FROM), non il mittente visibile: per DMARC conta solo se è allineato con il From. Gmail e Yahoo chiedono SPF o DKIM a tutti i mittenti, e Gmail, Yahoo e Outlook.com chiedono SPF, DKIM e DMARC a chi invia grandi volumi.

La risposta breve: il record SPF è un record DNS di tipo TXT, pubblicato sul tuo dominio, che elenca i server autorizzati a spedire email a nome di quel dominio. È una riga sola: comincia con v=spf1, elenca le fonti di invio con meccanismi come include e ip4, e chiude con all, che decide come trattare tutto il resto. Ogni dominio ne può avere uno solo.

Se la posta parte solo da Google Workspace, il record indicato da Google è v=spf1 include:_spf.google.com ~all. Se parte solo da Microsoft 365, quello indicato da Microsoft è v=spf1 include:spf.protection.outlook.com -all. Il resto dell'articolo serve quando le fonti sono più di una: il CRM, la piattaforma delle newsletter, il gestionale che manda le fatture.

Cos'è un record SPF e cosa controlla davvero

SPF (Sender Policy Framework) è definito dalla RFC 7208, standard IETF di aprile 2014 tuttora in vigore: il RFC Editor le registra tre aggiornamenti e nessun successore. Il titolare del dominio pubblica nel DNS l'elenco degli host autorizzati; chi riceve un messaggio controlla se l'IP di chi lo consegna è in quell'elenco.

Conta quale dominio viene controllato. SPF verifica quello del comando SMTP MAIL FROM, il mittente tecnico della busta, e può verificare il nome dichiarato nel saluto HELO. Non verifica il mittente visibile nel campo From: chi spedisce può ottenere un esito positivo con un dominio suo e mostrare nell'intestazione un mittente diverso (RFC 7208, sezione 11.2).

Per questo esiste DMARC, che chiede al dominio autenticato di corrispondere a quello del From. La RFC 9989, che da maggio 2026 definisce DMARC, precisa che conta solo la verifica SPF del MAIL FROM (sezione 4.4.2).

Degli esiti possibili (RFC 7208, sezione 2.6) ne servono quattro: pass (autorizzato), fail (non autorizzato), softfail (probabilmente non autorizzato) e permerror, il record non interpretabile che va corretto nel DNS.

La sintassi, pezzo per pezzo

Il record si legge da sinistra a destra. Il primo termine è la versione, v=spf1: i record che non cominciano esattamente così vengono scartati (sezione 4.5). Poi vengono i meccanismi:

ip4 e ip6: un indirizzo o una rete in notazione CIDR, per esempio ip4:203.0.113.0/24.
a e mx: gli indirizzi dei record A e AAAA, o dei server MX, di un dominio.
include: rimanda al record SPF di un altro dominio, di solito un fornitore. Per la RFC il nome è stato scelto male: non copia i meccanismi dell'altro record, ne usa solo l'esito. Se il dominio incluso non ha un record SPF, il risultato è un permerror.
exists e ptr: il primo serve a schemi complessi basati su macro, il secondo non va pubblicato, perché lento e meno affidabile (sezione 5.5).
all: corrisponde sempre, quindi va in fondo e vale per tutto ciò che non è stato elencato. I meccanismi scritti dopo vengono ignorati.

Davanti a ogni meccanismo può stare un qualificatore: + per pass (il predefinito, che di solito si omette), - per fail, ~ per softfail, ? per neutral. La valutazione si ferma al primo meccanismo che corrisponde. Se nessuno corrisponde e il record non chiude con all né con un redirect, l'esito è neutral, come con ?all: la RFC consiglia di chiudere sempre in modo esplicito (sezione 4.7). Il modificatore redirect=, che fa usare a un dominio il record di un altro, è pensato per domini della stessa organizzazione (sezione 6.1); per un fornitore esterno si usa include.

Esempi di record SPF da adattare

Solo Google Workspace: v=spf1 include:_spf.google.com ~all, dalla guida Google Configurare SPF.
Solo Microsoft 365: v=spf1 include:spf.protection.outlook.com -all, dalla documentazione Microsoft Learn.
Google Workspace e Microsoft 365 insieme: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all, dalla tabella della guida Google.
Microsoft 365 più un server di posta interno: v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all, sullo schema dell'esempio Microsoft, con l'IP pubblico del tuo server.
Un dominio che non spedisce posta, come un marchio registrato e mai usato: v=spf1 -all. Per la RFC 7208 pubblicarlo è una pratica consolidata (sezione 10.1.2), e Microsoft lo indica per i domini parcheggiati.

Come si configura, in cinque passi

Fai l'inventario di chi spedisce a nome del dominio. La guida Google elenca server web, server di posta interni, gateway in uscita, moduli di contatto del sito e ogni servizio terzo che invia per conto tuo. Il valore da inserire lo indica ciascun servizio.
Scrivi un solo record. Se il dominio ne ha già uno, si modifica quello. Due record SPF sullo stesso nome non sono ammessi (RFC 7208, sezione 3.2) e producono un permerror: succede quando chi attiva un nuovo servizio aggiunge un record invece di modificare l'esistente.
Pubblicalo come TXT sul dominio. Nel pannello DNS il tipo è TXT e il nome è il dominio stesso, spesso indicato con @, non un sottodominio dedicato come per DMARC. Il vecchio tipo di record SPF non va usato: la RFC 7208 lo ha abbandonato (sezione 3.1). Il record si scrive dal provider DNS, non dalle console di Google Workspace o Microsoft 365.
Copri i sottodomini che spediscono. Google e Microsoft ricordano che ognuno ha bisogno di un record proprio: quello di tuodominio.it non vale per marketing.tuodominio.it.
Verifica e tieni aggiornato. Google avverte che possono servire fino a 48 ore prima che il record sia operativo. Poi invia un messaggio a una casella esterna e cerca l'esito spf nel campo Authentication-Results dell'intestazione. A ogni servizio aggiunto o dismesso il record va aggiornato.

~all o -all: perché Google e Microsoft consigliano cose diverse

Google consiglia ~all. Con il softfail i server di destinazione in genere accettano i messaggi dei mittenti non elencati e li segnano come sospetti; con -all e un record incompleto, più posta legittima rischia il rifiuto o lo spam. Per trovare i mittenti dimenticati Google indica i report DMARC.
Microsoft consiglia -all per i domini Microsoft 365, perché raccomanda anche DKIM e DMARC: è la policy DMARC a stabilire cosa fare dei messaggi che falliscono. La sua documentazione aggiunge che DMARC considera un fallimento SPF sia -all sia ~all, ma che con ~all la policy DMARC viene di fatto ignorata sui messaggi privi di firma DKIM.

La RFC 7208 aiuta a leggerle: un dominio che vuole permettere ai riceventi una conclusione negativa deve chiudere con -all (sezione 2.1), mentre su un softfail il ricevente non dovrebbe rifiutare sulla base di quel solo esito (sezione 8.5).

In pratica la decisione vera si sposta su DMARC. Finché l'inventario non è completo e DKIM non firma tutti i flussi, ~all limita il rischio di perdere posta legittima; quando i report DMARC confermano che i mittenti legittimi passano tutti, -all è coerente con una policy in applicazione. Il ?all resta fuori: per Microsoft è un valore di prova.

Il limite delle 10 ricerche DNS e gli altri errori

La RFC 7208 (sezione 4.6.4) conta i termini che costringono il ricevente a interrogare il DNS: include, a, mx, ptr, exists e redirect. Non possono essere più di 10; oltre, l'esito è permerror. ip4, ip6 e all non contano.

Il conto comprende le ricerche annidate. Microsoft fa l'esempio di un include che punta a un record con altri tre include: in tutto sono quattro ricerche. E poiché la valutazione si ferma alla prima corrispondenza, un record oltre il limite può funzionare per alcuni messaggi e fallire per altri.

Per rientrare, Google raccomanda di togliere gli include dei servizi dismessi e i meccanismi duplicati. Microsoft aggiunge due strade. La prima è spostare newsletter e servizi esterni su un sottodominio come marketing.tuodominio.it, che ha le sue 10 ricerche e tiene i loro problemi lontani dalla reputazione della posta dei dipendenti. La seconda è sostituire un include con gli IP (il flattening), solo per fornitori con indirizzi stabili e mai per Microsoft 365.

L'altro errore che rompe il record è la sintassi: uno sbaglio in qualsiasi punto produce un permerror (RFC 7208, sezione 4.6). Microsoft elenca i più comuni: il punto finale dopo il dominio (include:spf.protection.outlook.com.), l'uguale al posto dei due punti (include=), lo spazio dopo i due punti.

Dove SPF non arriva

Il primo limite è l'inoltro. SPF guarda l'IP dell'ultimo server che consegna: quando una mailing list o un inoltro automatico rispedisce il messaggio conservando il mittente originale della busta, il controllo fallisce (RFC 7208, sezione 10.3). Per questo a SPF si affianca DKIM, che firma il messaggio invece di guardare chi lo consegna.

Il secondo è l'allineamento. Se una piattaforma esterna usa nella busta un dominio suo, SPF dà pass al suo dominio e non al tuo, e ai fini di DMARC quel pass non vale (RFC 9989, sezione 4.4.2). Serve che il servizio usi nella busta un dominio tuo, se lo consente (con l'allineamento rilassato, il predefinito, basta un sottodominio); altrimenti l'allineamento passa da DKIM. E chi vuole arrivare a p=reject non deve affidarsi al solo SPF per superare DMARC (RFC 9989, sezione 8).

SPF, infine, riguarda la posta che parte a tuo nome. Non ferma un dominio somigliante né una casella reale compromessa, due dei canali della truffa del CEO, e non filtra la posta in arrivo. Per quel versante servono le misure descritte in cos'è il phishing e cosa comporta per un'azienda.

Cosa chiedono Gmail, Yahoo e Outlook.com

Google: dal 1° febbraio 2024 tutti i mittenti verso account Gmail devono configurare SPF o DKIM. Chi invia più di 5.000 messaggi al giorno deve avere SPF e DKIM, un record DMARC (la policy può restare su none) e il From allineato con il dominio SPF o DKIM. Le FAQ precisano che la soglia si conta su tutto ciò che parte dallo stesso dominio principale, sottodomini compresi.
Yahoo: a tutti i mittenti chiede almeno SPF o DKIM; ai mittenti massivi entrambi, più DMARC almeno a p=none con esito pass e il From allineato.
Microsoft: il 2 aprile 2025 ha annunciato requisiti analoghi per Outlook.com, il servizio consumer di hotmail.com, live.com e outlook.com. Oltre i 5.000 messaggi al giorno SPF e DKIM devono passare e DMARC deve essere almeno a p=none, allineato. Con l'aggiornamento del 29 aprile ha indicato il rifiuto dei messaggi non conformi dal 5 maggio 2025, con il codice 550 5.7.515.

Il sottodominio per le newsletter suggerito da Microsoft, quindi, aiuta la reputazione e il conto delle ricerche DNS, ma non toglie volume dalla soglia di Google. E anche sotto soglia, avverte Google, i messaggi dei mittenti non inclusi nel record SPF finiscono più facilmente nello spam.

In sintesi

Un record SPF è una riga TXT sul dominio: v=spf1, le fonti autorizzate, una chiusura con ~all o -all. Uno solo per dominio, al massimo 10 ricerche DNS, un record proprio per ogni sottodominio che spedisce. Controlla il dominio della busta, non il mittente visibile: per questo lavora insieme a DKIM e DMARC, e sono i report DMARC a dirti se l'inventario dei mittenti era completo.

Per vedere come sono messi adesso i record del tuo dominio, prova il verificatore gratuito SPF, DKIM e DMARC: legge i record pubblicati e ti dice cosa correggere.

Domande frequenti

Come si scrive un record SPF?

Si pubblica un record TXT sul dominio, spesso indicato con @ nel pannello DNS, con una riga che comincia con v=spf1, elenca le fonti autorizzate e chiude con all. Per esempio v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all autorizza un server di posta interno e Microsoft 365 e dichiara non autorizzato tutto il resto. Per la RFC 7208 i record che non cominciano esattamente con v=spf1 vengono scartati.

Qual è il record SPF per Google Workspace?

Se la posta parte solo da Google Workspace, la guida Google indica v=spf1 include:_spf.google.com ~all. Se spediscono anche altri servizi, i loro include si aggiungono nello stesso record: con Microsoft 365, per esempio, diventa v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all. Google avverte che possono servire fino a 48 ore prima che il record sia operativo.

Meglio ~all o -all nel record SPF?

Google consiglia ~all, con cui i server di destinazione in genere accettano i messaggi dei mittenti non elencati e li segnano come sospetti. Microsoft consiglia -all per i domini Microsoft 365, insieme a DKIM e DMARC. Finché l'inventario dei mittenti non è completo, ~all limita il rischio di perdere posta legittima; quando i report DMARC confermano che tutti i mittenti legittimi passano, -all è coerente con una policy DMARC in applicazione.

Posso avere due record SPF sullo stesso dominio?

No. La RFC 7208 non ammette più di un record SPF sullo stesso nome, e se ne trova due il controllo restituisce permerror. Per aggiungere un servizio si modifica il record esistente inserendo il suo include. I sottodomini che spediscono, invece, hanno ciascuno il proprio record.

Cosa succede se il record SPF supera le 10 ricerche DNS?

Il controllo SPF fallisce con un permerror e il server ricevente può rifiutare il messaggio. Contano include, a, mx, ptr, exists e redirect, comprese le ricerche dei record inclusi; ip4, ip6 e all no. Si rientra togliendo i servizi dismessi, spostando newsletter e servizi esterni su un sottodominio oppure, solo per fornitori con indirizzi stabili, sostituendo l'include con gli indirizzi IP.