Verifica e genera il record SPF

Come verificare un record SPF

1. Scrivi un dominio nel campo qui sopra. Va bene anche un indirizzo email completo. Lo strumento tiene solo il dominio.
2. Clicca su Verifica il record SPF. Lo strumento legge dal DNS pubblico il record attuale, lo stesso che legge un server di destinazione.
3. Leggi prima il riepilogo. Ti dice se il record è valido, se ha avvisi o se non funziona.
4. Poi leggi l'elenco dei problemi, se ce ne sono. Per ognuno trovi cosa cambiare.
5. Più in basso trovi la spiegazione di ogni parte del record, con le ricerche DNS che richiede. Apri un include per vedere cosa autorizza il servizio che c'è dietro.

Il link nella barra degli indirizzi ripete la stessa verifica SPF, quindi puoi inviarlo a un collega o al gestore del tuo DNS. C'è un limite: il server di destinazione verifica SPF in base all'indirizzo IP del server che ha inviato il messaggio. Questo strumento non ha un messaggio da esaminare, quindi verifica il record in sé. Non può valutare le parti costruite con le macro SPF, che cambiano per ogni server di invio.

Cos'è un record SPF?

Un record SPF è un record TXT nel DNS di un dominio. Elenca i server che possono inviare email per quel dominio. SPF sta per Sender Policy Framework e le regole sono nella RFC 7208. Un dominio che usa Google Workspace ha spesso un record come questo:

v=spf1 include:_spf.google.com ~all

v=spf1 indica che è un record SPF. include:_spf.google.com autorizza tutti i server dell'elenco di Google. ~all dice ai server di destinazione di trattare con sospetto le email da qualsiasi altro server.

Quando arriva un messaggio, il server di destinazione prende il dominio dall'indirizzo di rimbalzo, chiamato Return-Path. Legge il record SPF di quel dominio e controlla se l'indirizzo IP del server di invio è nell'elenco. SPF non guarda l'indirizzo From che vedi nella tua casella. Per questo funziona insieme a DKIM e DMARC. Per sapere come funzionano i tre record, leggi la nostra guida a SPF, DKIM e DMARC.

Da febbraio 2024 Gmail richiede SPF o DKIM a ogni mittente, ed entrambi ai mittenti di massa. Yahoo ha le stesse regole.

Cosa significa ogni parte di un record SPF

Un record SPF è un elenco di termini separati da spazi. I server di destinazione li leggono da sinistra a destra e si fermano al primo che corrisponde al server di invio.

Ogni parte può iniziare con un qualificatore, che decide il risultato in caso di corrispondenza. + significa pass ed è il valore predefinito, quindi nessuno lo scrive. - significa fail, ~ significa softfail e ? significa neutral. Per questo la stessa parola, all, può chiudere un record come -all, ~all o ?all.

I nomi non distinguono tra maiuscole e minuscole, quindi Include: funziona come include:. La RFC 7208 consiglia di chiudere ogni record con all o un redirect. Senza nessuno dei due, i server non elencati ricevono un risultato neutro.

Il limite di 10 ricerche DNS

Ogni include, a, mx, ptr, exists e redirect obbliga il server di destinazione a fare una ricerca DNS. La RFC 7208 ne permette 10 in tutto. Contano anche le ricerche dentro un include, quindi un solo include può costarne diverse. ip4, ip6 e all non costano nulla. Quando un record ne richiede più di 10, il server di destinazione si ferma e restituisce un permerror. A quel punto SPF fallisce.

Il limite si raggiunge facilmente. Abbiamo misurato sul DNS pubblico quanto costano gli include più comuni: Google Workspace 1, Microsoft 365 1, Salesforce 2, Mailgun 5 e Freshdesk 7. Un'azienda che usa Google Workspace e aggiunge Mailgun e Freshdesk ha già bisogno di 13 ricerche. Uno studio del 2024 sui record SPF nei domini .com, .net, .org e .se ha rilevato che il 6,5% richiedeva più di 10 ricerche. Gli include dei record di due soli provider di hosting causavano l'83,7% di questi casi.

Anche i costi cambiano. L'include di Google costava 4 ricerche fino a dicembre 2025, quando Google ha sostituito i suoi include annidati con un unico elenco. Alcune guide e alcuni generatori SPF dicono ancora 4. Lo strumento qui sopra conta il numero reale ogni volta che lo usi.

Superare il limite non blocca sempre tutti i messaggi. Microsoft fa notare che i server di destinazione si fermano alla prima corrispondenza. Le email da un server elencato all'inizio possono ancora passare, mentre quelle da un server elencato alla fine falliscono. Per questo il problema sembra casuale. Conta sempre le ricerche dell'intero record.

C'è un secondo limite. Una ricerca che non trova nulla è una ricerca vuota (void lookup), per esempio l'include di un dominio che non esiste più. La RFC 7208 dice che i server di destinazione dovrebbero fermarsi dopo 2 ricerche di questo tipo.

Come restare entro le 10 ricerche DNS

1. Togli gli include dei servizi che non usi più.
2. Togli gli include che un servizio non chiede più. Mailchimp, Postmark, Brevo e Klaviyo non ne hanno bisogno sul dominio principale, mentre SendGrid e Amazon SES mettono il loro su un sottodominio. L'elenco è più in basso.
3. Elenca i tuoi server con ip4 e ip6 invece di a o mx. La RFC 7208 consiglia questo ordine, e gli indirizzi IP non costano ricerche.
4. Invia una parte delle email da un sottodominio, come news.example.com. Ogni sottodominio ha il suo record e le sue 10 ricerche.

Alcuni servizi offrono l'appiattimento SPF (flattening), che sostituisce gli include con i loro indirizzi IP. Fa risparmiare ricerche, ma i provider cambiano i loro indirizzi e un record appiattito non si aggiorna. Microsoft consiglia di appiattire solo i servizi con intervalli IP stabili e documentati, mai Microsoft 365. Consiglia anche di ricontrollare il risultato almeno ogni tre mesi.

Include SPF per Google Workspace, Microsoft 365 e altri servizi

Questi sono i valori include indicati nella guida di configurazione di ogni servizio, con le ricerche DNS che richiede ciascuno. Abbiamo misurato i costi sul DNS pubblico il 12 ottobre 2026. Quando configuri un servizio, copia il valore dalla sua guida, perché alcuni dipendono dalla tua regione o dal tuo account.

HubSpot dà a ogni account un include diverso, che finisce in hubspotemail.net. Copialo dalle impostazioni email di HubSpot. Costa 1 ricerca.

Servizi che di solito non hanno bisogno di un include

SPF si verifica sull'indirizzo di rimbalzo, non sull'indirizzo From. Molti servizi di invio ora usano un proprio indirizzo di rimbalzo, o un tuo sottodominio. Un loro include sul dominio principale non serve a niente e consuma solo ricerche DNS.

• Mailchimp. La configurazione del dominio di Mailchimp ora chiede solo i record DKIM e DMARC, non SPF.
• Postmark. Postmark dice che SPF non è più necessario. Invia con un proprio indirizzo di rimbalzo, o con un record Return-Path che punti a Postmark.
• Brevo. Brevo dice che SPF non è necessario, a meno che tu non invii da un indirizzo IP dedicato.
• Klaviyo. Klaviyo dice che di solito non serve aggiungere un record SPF.
• SendGrid. L'autenticazione del dominio di SendGrid mette SPF su un sottodominio che crea per te, come em1234.tuodominio.it.
• Amazon SES. SES ne ha bisogno solo su un sottodominio MAIL FROM personalizzato, come bounce.tuodominio.it. Per impostazione predefinita usa un proprio indirizzo di rimbalzo.

Lo strumento segnala questi include quando li trova nel tuo record.

Come generare un record SPF

Usa la scheda Genera qui sopra per creare un record SPF. Spunta i servizi che inviano le tue email e il generatore scrive il record e conta le sue ricerche DNS. Se il tuo dominio ha già un record, caricalo prima, così lo completi invece di sostituirlo. Ecco i passaggi da seguire:

1. Elenca ogni servizio che invia email con il tuo dominio. Non pensare solo al provider della casella: newsletter, CRM, helpdesk, fatturazione, moduli del sito. I report DMARC mostrano i mittenti che hai dimenticato.
2. Trova l'include di ognuno nella sua guida di configurazione, o spuntalo nello strumento. Per i tuoi server di posta, usa i loro indirizzi IP.
3. Scegli la chiusura: ~all o -all. La sezione successiva spiega la differenza.
4. Pubblicalo come un unico record TXT sul dominio stesso. Molti gestori DNS chiamano questo nome @. Se esiste già un record che inizia con v=spf1, modificalo invece di aggiungerne un secondo.
5. Aspetta qualche minuto e verifica di nuovo il dominio con lo strumento qui sopra.

Ogni nome di dominio che invia email ha bisogno del suo record, perché i sottodomini non usano il record del dominio padre. Anche un dominio o un sottodominio che non invia mai email dovrebbe averne uno: v=spf1 -all. La RFC 7208 la definisce una buona pratica consolidata. Così nessun altro può inviare email che superano SPF a nome di quel dominio. L'NCSC britannico suggerisce di aggiungere a questi domini anche un record DMARC con p=reject e un record MX nullo.

Un record più lungo di 255 caratteri va diviso in più stringhe dentro lo stesso record TXT. I server di destinazione uniscono le stringhe senza spazi, quindi metti lo spazio dentro una stringa, non tra due stringhe. Controlla come il tuo gestore DNS tratta i valori lunghi.

~all o -all: quale chiusura usare

I grandi provider non sono d'accordo, e ognuno ha le sue ragioni.

• Google consiglia ~all.
• M3AAWG, un gruppo di settore di cui fanno parte grandi provider di posta e grandi mittenti, dice che i record dovrebbero finire con ~all. Chiede anche ai server di destinazione di non rifiutare per un fail SPF prima del controllo DMARC.
• Microsoft consiglia -all, a patto che siano configurati anche DKIM e DMARC.

Il rischio di -all è che alcuni server di destinazione rifiutino il messaggio durante la consegna, prima di controllare DMARC. La RFC 9989, lo standard DMARC del 2026, fa notare che queste email non compaiono mai nei tuoi report DMARC. Così i problemi sono più difficili da trovare.

In pratica ~all è la scelta più sicura per un dominio che invia email, soprattutto mentre stai ancora cercando tutti i tuoi mittenti. Se hai DMARC su quarantine o reject, è comunque DMARC a decidere cosa succede alle email che falliscono. Usa -all sui domini che non inviano nessuna email. Non usare mai +all, che fa passare ogni server, ed evita ?all, che vale come non avere nessun record.

Cosa significa il risultato della tua verifica SPF

I server di destinazione usano parole proprie per l'esito di una verifica SPF. Le vedi nelle intestazioni dei messaggi, come spf=pass o spf=softfail, e nei report DMARC:

Errori comuni nel record SPF e come correggerli

Una scansione del 2023 su 12 milioni di domini popolari ha trovato SPF sul 56,5% dei domini ed errori nel 2,9% dei record SPF. L'errore più comune era un include o un redirect verso un nome senza record SPF. Al secondo posto c'erano le ricerche DNS in eccesso.

Due record SPF sullo stesso dominio

Succede spesso quando la guida di un nuovo servizio dice “aggiungi questo record TXT” e qualcuno lo aggiunge accanto a quello vecchio. Due record causano un permerror. Uniscili in uno solo. Inizia con un solo v=spf1, elenca ogni include e indirizzo IP e chiudi con un solo all.

Un include che punta a un dominio senza SPF

Se un include punta a un dominio senza record SPF, l'intero record fallisce con un permerror. Può essere un errore di battitura, o un servizio che ha chiuso o ha cambiato il suo include. Toglilo o sostituiscilo con il valore attuale del servizio.

+all, ?all o nessun all alla fine

+all autorizza ogni server su internet, quindi il record non protegge niente. ?all, o l'assenza di all, dà un risultato neutro, che i server di destinazione trattano come l'assenza di un record. Chiudi il record con ~all o -all.

ptr nel record

La RFC 7208 dice che ptr non va usato. È lento, costa una ricerca DNS ed è meno affidabile di altri meccanismi quando il DNS ha problemi. Sostituiscilo con voci ip4 e ip6 per i server che doveva coprire.

Errori di battitura

Uno spazio dopo i due punti, un indirizzo IPv4 incompleto o una parola che SPF non conosce causano tutti un permerror. Un errore è meno evidente: include=example.com, con il segno uguale, viene letto come un'impostazione sconosciuta e saltato. Così quel servizio non viene mai autorizzato. Lo strumento segnala tutti questi errori.

Tre dettagli che le guide SPF spesso sbagliano

• “Un record SPF non può contenere lettere maiuscole.” La RFC 7208 dice che i nomi non distinguono tra maiuscole e minuscole.
• “Un record SPF può avere al massimo 255 caratteri.” Il limite di 255 vale per ogni stringa. Un record più lungo si divide in più stringhe. La RFC 7208 chiede solo che l'intera risposta DNS resti piccola, sotto i 450 byte circa.
• “Puoi avere fino a 10 include.” Il limite conta le ricerche DNS, e contano anche quelle dentro gli include.

SPF è solo una parte dell'autenticazione email

Anche un SPF superato ha dei limiti. Nella stessa scansione del 2023, il 34,7% dei domini autorizzava email da più di 100.000 indirizzi IP. SPF si rompe anche quando qualcuno inoltra il tuo messaggio, perché il server che inoltra non è nel tuo record.

DKIM firma il messaggio stesso, quindi di solito sopravvive all'inoltro. DMARC controlla che SPF o DKIM sia passato per lo stesso dominio dell'indirizzo From. Se nessuno dei due è passato, dice ai server di destinazione cosa fare. Molti servizi di invio superano SPF con un proprio dominio di rimbalzo, che non corrisponde al tuo indirizzo From. Un Return-Path personalizzato presso il servizio risolve il problema. Configura gli altri due record con il generatore DKIM e il generatore DMARC. Con l'MX Lookup verifichi dove il tuo dominio riceve la posta.

Inoltre l'autenticazione non aiuta con gli indirizzi che non esistono. Le email inviate lì rimbalzano, e un alto tasso di rimbalzo danneggia la consegna. Verifica i singoli indirizzi con la verifica email, o un'intera lista con la verifica email in blocco. Per una definizione breve da condividere con il tuo team, leggi la voce del glossario sul record SPF.