Record SPF del DNS: come funziona e come configurarlo

Ogni e-mail inviata dalla tua organizzazione riflette la reputazione del tuo dominio. Se il tuo record SPF è configurato in modo errato o è del tutto assente, i server di ricezione non hanno alcun modo affidabile per verificare che l'e-mail provenga effettivamente da te. Le e-mail legittime finiscono nella cartella dello spam. Le campagne di marketing vengono respinte. Gli hacker inviano messaggi che sembrano provenire dal tuo dominio.

L'SPF (Sender Policy Framework) è uno dei tre principali di autenticazione delle e-mail , insieme a DKIM e DMARC, che indica ai server di posta riceventi quali indirizzi IP sono autorizzati a inviare email per conto del proprio dominio. Viene pubblicato come record DNS TXT. A prima vista, sembra semplice. In pratica, l'SPF è il punto di partenza della maggior parte dei problemi di autenticazione delle email. 

Questa guida spiega in dettaglio cos'è un record SPF, come funziona la verifica SPF passo dopo passo, come crearne uno e come risolvere gli errori SPF più comuni, compreso il limite di 10 ricerche DNS che, senza dare alcun preavviso, impedisce la consegna delle e-mail alle organizzazioni in crescita.

Che cos'è un record SPF DNS?

Un record DNS SPF (Sender Policy Framework) è un tipo di record DNS TXT che specifica quali server di posta sono autorizzati a inviare e-mail per conto del proprio dominio. Aiuta i server di posta destinatari a verificare che i messaggi in arrivo provengano da fonti legittime, riducendo il rischio di spoofing e phishing. Quando viene ricevuta un'e-mail, il server controlla il record SPF del dominio del mittente per confermare che l'IP di invio sia autorizzato. 

Se l'indirizzo IP non è presente nell'elenco, il messaggio potrebbe essere contrassegnato, respinto o inviato nella cartella dello spam. Una corretta configurazione del record SPF migliora la deliverability delle e-mail e rafforza l'autenticazione del dominio.

Puoi verificare immediatamente il record SPF del tuo dominio con uno strumento gratuito di ricerca SPF. Ci vogliono cinque secondi e ti mostra esattamente cosa è pubblicato nel tuo DNS.

Come funziona l'autenticazione SPF?

L'autenticazione SPF segue un processo strutturato di ricerca e convalida DNS ogni volta che viene ricevuta un'e-mail:

• Il tuo dominio pubblica un record SPF sotto forma di voce TXT nel DNS. Questo record definisce tutte le fonti di invio autorizzate utilizzando meccanismi quali ip4, ip6, includee una, insieme a una politica predefinita (-all, ~all, o ?all).
• Quando viene inviata un'e-mail, il server mittente include un indirizzo Return-Path (mittente della busta) che indica il dominio responsabile della consegna.
• Il server di posta in arrivo estrae il dominio dall'indirizzo Return-Path.
• Esegue una query DNS per recuperare il record SPF associato a quel dominio.
• L'indirizzo IP del server mittente viene quindi confrontato con ciascun meccanismo presente nel record SPF, elaborato in ordine fino a quando non si ottiene una corrispondenza o si giunge a una decisione relativa alla politica.
• SPF impone un limite di 10 ricerche DNS durante questa valutazione per evitare una ricorsione eccessiva; il superamento di tale limite comporta un errore PermError.
• In base all'esito, SPF restituisce un risultato come Pass, Fail, SoftFail, Neutral, None, PermError o TempError.
• Il server ricevente utilizza questo risultato, insieme all'autenticazione DKIM e alla conformità alle politiche DMARC, per determinare come il messaggio debba essere gestito (consegnato, messo in quarantena o rifiutato).

Un dettaglio fondamentale: l'SPF verifica il dominio del Return-Path (mittente dell'involucro), non l'intestazione From visibile. Se questi domini differiscono, come spesso accade con le piattaforme di invio di terze parti, l'SPF potrebbe superare il controllo, ma l'allineamento DMARC può fallire, il che influisce direttamente sul posizionamento nella posta in arrivo.

Ogni codice di risultato SPF ha un significato pratico specifico:

Report aggregati DMARC ti mostrano esattamente quali email superano e quali non superano il controllo SPF su tutte le tue fonti di invio. Senza i report DMARC, gli errori SPF passano inosservati e non te ne accorgi finché qualcuno non presenta un reclamo.

Spiegazione della sintassi e del formato dei record SPF

Per comprendere la sintassi SPF occorre innanzitutto leggere un record completo e capire come viene valutata ogni sua parte. Ecco un esempio tipico:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (dove /24 rappresenta un intervallo di 256 indirizzi IP utilizzando la notazione CIDR (Classless Inter-Domain Routing))

Questa singola riga indica ai server di ricezione quali mittenti sono autorizzati a inviare e-mail per il tuo dominio e come comportarsi nel caso in cui un mittente non figuri nell'elenco.

Tag versione SPF (v=spf1)

Ogni record SPF deve iniziare con v=spf1. Questo identifica il record TXT come una politica SPF. Non esistono altre versioni valide. Se questo tag manca o è errato, il record viene ignorato completamente.

Meccanismi SPF (mittenti autorizzati) 

I meccanismi stabiliscono chi è autorizzato a inviare e-mail. Vengono valutati da sinistra a destra e il primo che corrisponde determina il risultato.

Tra includono: Il meccanismo è quello più comunemente usato e quello che causa più problemi. Ogni include: innesca una ricerca DNS ricorsiva. Se il record SPF di Google include altri tre domini, questi vengono tutti conteggiati ai fini del limite di 10 ricerche.

Un punto che spesso crea confusione: il un in SPF fa riferimento al record A DNS del dominio. Non crea un “record A per SPF” separato. Quando si aggiunge un al tuo record SPF, stai autorizzando qualsiasi indirizzo IP a cui risolve il record A del tuo dominio.

Modificatori (redirect=)

I modificatori controllano il comportamento della valutazione SPF piuttosto che definire i mittenti.

• redirect=
  Trasferisce l'intera valutazione SPF a un altro dominio. A differenza di include:, che aggiunge un’altra politica al proprio record, redirect= sostituisce completamente la tua valutazione.
  Utilizzalo solo quando un dominio deve ereditare integralmente la configurazione SPF di un altro dominio.

Limite di ricerca DNS (vincolo critico)

SPF consente un massimo di 10 ricerche DNS per ogni valutazione. Meccanismi quali includono:, un, mx, esiste:, e redirect= contribuiscono tutti a questo limite.

Se il limite viene superato, SPF restituisce un PermError e l'autenticazione fallisce, anche se il mittente è legittimo. Ecco perché i record di grandi dimensioni e complessi richiedono spesso un'ottimizzazione (come la riduzione degli include inutilizzati o l'appiattimento).

Qualificazioni SPF (il meccanismo "all")

Il termine di qualificazione su tutto alla fine del tuo record SPF definisce la tua politica SPF: cosa succede alle email provenienti da server non esplicitamente elencati:

SPF funziona come un insieme di regole logiche. Il server ricevente legge il record da sinistra a destra, verifica ogni meccanismo e si ferma alla prima corrispondenza. Se non viene trovata alcuna corrispondenza, il si applica la regola .

Un record SPF ben strutturato è:

• Completo (compresi tutti i mittenti legittimi)
• Efficiente (entro i limiti della ricerca)
• Rigoroso (utilizzando -tutti una volta convalidato)

Ciò garantisce un'autenticazione accurata e impedisce l'uso non autorizzato del tuo dominio per l'invio di e-mail.

Come creare e pubblicare un record SPF

Per configurare un record SPF è necessario identificare tutte le fonti di invio legittime, definirle chiaramente nel DNS e verificare che la configurazione funzioni come previsto. Segui i 5 passaggi riportati di seguito nell'ordine indicato.

Passaggio 1: Identifica tutte le tue fonti di invio

Elenca tutti i servizi che inviano e-mail per conto del tuo dominio. In genere, questi includono il tuo provider di posta elettronica principale (come Google Workspace o Microsoft 365), le piattaforme di marketing (come Mailchimp o HubSpot), i sistemi di gestione delle relazioni con i clienti (CRM) (Salesforce), gli strumenti di assistenza (Zendesk) e i servizi di posta elettronica transazionale (SendGrid, Amazon SES). Ciascuno di questi servizi invia email da infrastrutture diverse, pertanto tutti devono essere autorizzati in modo esplicito. La maggior parte dei provider pubblica nella propria documentazione un valore SPF "include", che indica ai server destinatari di considerare attendibili i propri indirizzi IP di invio.

Passaggio 2: Crea il tuo record SPF

Un record SPF è una voce TXT di una sola riga che inizia con v=spf1. È quindi possibile definire i mittenti autorizzati utilizzando i seguenti meccanismi:

• includere: per i servizi di terze parti (ad es., include:_spf.google.com)
• ip4: oppure ip6: per indirizzi IP specifici o intervalli di indirizzi IP di cui hai il controllo
  I meccanismi vengono valutati da sinistra a destra. Alla fine, si definisce una politica:
• ~tutti (soft fail) contrassegna i mittenti non autorizzati come sospetti
• -all (hardfail) li esclude esplicitamente

Esempio:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Questo record indica ai server di ricezione quali sorgenti sono consentite e come gestire tutte le altre.

Passaggio 3: Pubblicare il record nel DNS

Accedi al tuo provider DNS (come Cloudflare, Route 53 o GoDaddy). Crea un nuovo record TXT per il tuo dominio principale:

• Host/Nome: @ (oppure lasciare vuoto, a seconda del provider)
• Valore: il tuo record SPF completo
  Una volta salvato, il record diventa accessibile pubblicamente tramite DNS. La propagazione delle modifiche potrebbe richiedere del tempo.

Fase 4: Verifica della registrazione

Dopo la pubblicazione, verificare che:

• Il record SPF è formattato correttamente (non presenta errori di sintassi)
• Tutto funziona correttamente
• Il numero totale di ricerche DNS non supera il limite di 10 (in caso di superamento, SPF restituisce un errore PermError)

La convalida garantisce che i server destinatari siano in grado di elaborare il tuo record in modo affidabile e senza errori.

Fase 5: Monitorare i risultati dell'SPF

L'SPF non è una configurazione che si effettua una volta sola. Man mano che si aggiungono o si rimuovono fonti di invio, è necessario aggiornare il record SPF. Per monitorare le prestazioni:

• Abilita DMARC per ricevere rapporti aggregati che mostrano i tassi di superamento/fallimento di SPF
• Verifica quali sorgenti superano o falliscono l'autenticazione
• Elimina i servizi inutilizzati e correggi i mittenti non allineati o non autorizzati

Importante: È consentito un solo record SPF per dominio. Se sono presenti più record TXT che iniziano con v=spf1 , la valutazione SPF fallisce completamente con un PermError. Unire sempre tutte le fonti di invio in un unico record completo.

Il limite di ricerca DNS SPF 10 (e perché compromette la funzionalità della tua posta elettronica)

La valutazione SPF non è illimitata. Secondo la RFC 7208, un server ricevente può eseguire al massimo 10 ricerche DNS durante l'elaborazione del record SPF. Se questo limite viene superato, SPF restituisce un PermError (errore permanente) e la verifica fallisce completamente.

Non si tratta di un errore parziale. Un PermError indica che l'SPF non può essere valutato in alcun modo. Di conseguenza, ogni e-mail inviata dal tuo dominio non supera l'autenticazione SPF, indipendentemente dal fatto che il mittente sia legittimo.

Cosa viene conteggiato ai fini del limite di 10 ricerche?

I seguenti meccanismi attivano le ricerche DNS:

• tra cui: (le più comuni e quelle con maggiore impatto)
• a
• mx
• ptr (obsoleto, ma se utilizzato viene comunque conteggiato)
• esiste:
• reindirizza a=

I meccanismi ip4: e ip6: non vengono conteggiati ai fini del limite di ricerca poiché fanno riferimento direttamente agli indirizzi IP, senza richiedere alcuna risoluzione DNS

Perché è facile superare questo limite

Il problema principale deriva dalle ricerche annidate (ricorsive).

Quando si aggiunge un "include:", non si aggiunge solo un riferimento, ma si eredita anche tutto ciò che è contenuto nel record SPF di quel provider.

Per esempio:

• Se includi Google → l'SPF di Google potrebbe includere molti altri domini
• Se si include Microsoft 365 → vengono aggiunte diverse altre voci di ricerca
• Si includono strumenti di marketing e transazionali → ognuno aggiunge la propria catena

Si accumulano rapidamente. Anche se il tuo record sembra breve, il numero effettivo di ricerche può superare le 10 durante la valutazione.

Il limite dei 2 "void lookup" (spesso trascurato)

SPF impone inoltre un limite di 2 ricerche non valide.

Si parla di ricerca senza risultati quando una query DNS non restituisce alcun risultato (dominio inesistente (NXDOMAIN) o risposta vuota).

Cause comuni:

• Esempi di dati errati o non aggiornati: domini
• Errori di battitura nei meccanismi SPF
• Riferimenti a domini che non esistono più

Se si verificano più di due ricerche non valide, SPF restituisce nuovamente un PermError.

A PermError non significa "fallimento per alcuni mittenti". Significa:

• Il valore SPF non è valido
• I server di ricezione non possono considerare attendibile la tua politica SPF
• L'SPF non offre di fatto alcuna protezione né autenticazione

Poiché l'SPF è uno dei segnali utilizzati dal DMARC, ciò può comportare anche:

• Errori DMARC (se DKIM non è allineato)
• Aumento della diffusione di spam
• Rifiuto del messaggio da parte di destinatari più rigorosi

Man mano che il numero delle tue e-mail aumenta, il tuo record SPF diventa naturalmente più complesso. Senza una gestione attiva:

• Il numero di ricerche aumenta in modo impercettibile
• I servizi non utilizzati rimangono registrati
• Gli errori si accumulano col tempo

L'SPF presenta questa vulnerabilità. Funziona in modo affidabile solo se i dati vengono mantenuti entro certi limiti, sono accurati e vengono aggiornati costantemente.

Quanto tempo ci vuole per raggiungere il limite (esempio reale)

Ecco come si presenta un tipico stack SaaS per il mercato medio in termini di ricerche DNS:

Non hai ancora aggiunto Zendesk, SendGrid, il tuo servizio di assistenza clienti o il tuo fornitore di servizi di gestione stipendi. Se la tua organizzazione utilizza Google Workspace insieme a quattro o cinque strumenti SaaS che inviano e-mail, probabilmente hai già raggiunto o superato il limite.

Come risolvere i problemi relativi al limite di ricerca SPF

Se il tuo record SPF supera il limite di 10 ricerche DNS, devi ridurne la complessità senza compromettere le fonti di invio legittime. Ecco i tre approcci pratici, in ordine di efficacia:

Eliminare i meccanismi superflui

Inizia con una verifica completa del tuo record SPF.

• Indicare tutti i includere: e meccanismo attualmente elencato
• Verifica se ogni servizio continua a inviare attivamente e-mail per il tuo dominio
• Elimina tutto ciò che non viene più utilizzato

Problemi comuni:

• Vecchi strumenti di marketing rimasti negli archivi
• Inclusioni duplicate tra sottodomini
• I servizi di prova o temporanei non sono mai stati rimossi

Tra gli elementi non utilizzati include: rimuovendo immediatamente si liberano una o più ricerche DNS. Questo è il modo più semplice e meno rischioso per rientrare nel limite.

Sostituisci includere: con ip4:/ip6: ove possibile

Se un mittente utilizza un insieme fisso e limitato di indirizzi IP, è possibile sostituire i suoi includere: con voci IP dirette.

• Esempio: sostituire include:vendor.com con ip4:x.x.x.x
• In questo modo si eliminano completamente le ricerche DNS per quel mittente

Quando funziona bene:

• Infrastruttura interna
• Indirizzi IP dedicati forniti da un provider
• Fornitori con intervalli di indirizzi IP chiaramente documentati e stabili

Compromesso da valutare:

• Ti assumi la responsabilità della manutenzione
• Se il provider aggiorna o ruota gli indirizzi IP, il tuo record SPF diventa obsoleto
• Ciò può causare errori SPF asimmptomatici fino a quando non viene risolto

Utilizzare questa opzione solo nei casi in cui la stabilità dell'IP sia prevedibile.

Utilizzo SPF di appiattimento o SPF Macros

Quando si utilizzano più servizi di terze parti, la pulizia manuale da sola di solito non basta. È necessario trovare un modo per ridurre il numero di ricerche senza compromettere la copertura.

Appiattimento SPF

• Risolve tutti includere: meccanismi nei loro indirizzi IP sottostanti
• Li sostituisce con un elenco semplice di ip4: / ip6: voci
• Elimina la maggior parte delle ricerche DNS

Limitazione:

• I record appiattiti sono statici
• Se un provider (come Google o Microsoft) aggiorna i propri indirizzi IP di invio, il tuo record non viene aggiornato automaticamente
• Ciò crea una lacuna per cui le e-mail legittime potrebbero non superare il controllo SPF senza alcun preavviso

Macro SPF (alternativa dinamica)

• Mantenere dinamica la valutazione dell'SPF controllando al contempo la profondità della ricerca
• Ridurre la dipendenza da lunghe catene di include
• Particolarmente indicato per ambienti in cui l'infrastruttura dei mittenti è soggetta a frequenti cambiamenti

Non sai quanti lookup utilizza il tuo record SPF? Verifica il numero di lookup con il nostro SPF Checker gratuito

Per le organizzazioni che devono rimanere al di sotto del limite di 10 ricerche senza dover gestire manualmente il DNS, PowerDMARC offre PowerSPF offre sia il tradizionale appiattimento e le moderne macro SPF, consentendoti di scegliere la tecnica più adatta al tuo ambiente. Il record si aggiorna automaticamente quando i provider di terze parti modificano i propri intervalli IP autorizzati.

Perché il solo SPF non basta

L'SPF è un metodo di autenticazione fondamentale, ma non è stato progettato per garantire una protezione completa contro le moderne tecniche di spoofing e gli abusi. Presenta tre limiti fondamentali che lo rendono insufficiente se utilizzato da solo.

Limite 1: SPF verifica il mittente dell'involucro, non l'intestazione "Da"

SPF verifica il Return-Path (mittente dell'involucro), ovvero il dominio utilizzato durante la trasmissione dell'e-mail. Tuttavia, agli utenti viene visualizzata l'intestazione "Da", che può essere diversa.

Questo crea una falla che gli hacker possono sfruttare:

• Un malintenzionato invia un'e-mail dal proprio dominio (che supera il controllo SPF)
• Impostano l'indirizzo del mittente visibile in modo che appaia come il tuo dominio o come quello di una persona di fiducia
• L'SPF viene superato perché il dominio mittente è legittimo
• Il destinatario continua a vedere un'identità falsificata

SPF non dispone di un meccanismo integrato per verificare che il dominio mittente corrisponda al mittente visibile. DMARC risolve questo problema applicando allineamento tra SPF (o DKIM) e il dominio dell'intestazione "Da".

Limite 2: l'SPF non funziona correttamente in caso di inoltro delle e-mail

SPF si basa sull'indirizzo IP del server mittente. Quando un'e-mail viene inoltrata:

• Il server di inoltro diventa la nuova origine di invio
• Il suo indirizzo IP viene confrontato con il record SPF del dominio originale. Poiché il server di inoltro non è elencato come mittente autorizzato, il controllo SPF fallisce.
• Poiché non è presente nell'elenco, SPF restituisce un errore

Questo accade anche quando l'e-mail è del tutto legittima. Non si tratta di un errore di configurazione, ma di un limite intrinseco al funzionamento dell'SPF.

Impatto:

• Le e-mail inoltrate legittime spesso non superano il controllo SPF
• I sistemi di ricezione devono fare affidamento su altri segnali (come DKIM) per convalidare il messaggio

Limite 3: l'SPF non dispone di un proprio meccanismo di segnalazione

SPF non offre alcuna funzionalità di reportistica integrata.

Senza uno strato aggiuntivo:

• Non sai quali sorgenti superano o falliscono il controllo SPF
• Non è possibile individuare i mittenti non autorizzati che utilizzano il tuo dominio
• Non hai alcuna visibilità sui problemi di autenticazione che compromettono la consegna

DMARC integra una funzione di reportistica, fornendo dati aggregati sui risultati di SPF e DKIM per tutti i destinatari.

Le moderne infrastrutture di posta elettronica, con le funzioni di inoltro, le mailing list, i mittenti di terze parti e le sofisticate tecniche di spoofing, hanno ormai superato i limiti di ciò che l'SPF è in grado di garantire da solo. DKIM aggiunge una firma crittografica che resiste all'inoltro, risolvendo il principale punto debole di SPF. DMARC è il livello di policy che collega SPF e DKIM all'intestazione "Da".

Per un confronto completo su come questi protocolli interagiscono tra loro, consulta la nostra guida su SPF vs DKIM vs DMARC.

Errori comuni nei record SPF (e come risolverli)

La maggior parte degli errori relativi all'SPF è riconducibile a pochi problemi ricorrenti. Il problema risiede principalmente nella mancanza di manutenzione e di verifica. Ecco come individuarli e risolverli con misure concrete.

Errore 1: presenza di più record SPF sullo stesso dominio.

SPF richiede una politica unica e autorevole. Se più record TXT iniziano con v=spf1, i server di ricezione non sono in grado di determinare quale valutare. Il risultato è un PermError, il che significa che l'SPF fallisce completamente per ogni messaggio.

Perché succede:

• I vari team inseriscono i dati in modo autonomo (marketing, IT, strumenti di assistenza)
• I nuovi fornitori forniscono istruzioni del tipo «aggiungi questo record» senza verificare la configurazione esistente

Come risolvere il problema:

• Verifica tutti i record TXT del tuo dominio
• Individuare tutte le voci relative all'SPF
• Unire tutti i meccanismi in un unico documento completo

Da tenere d'occhio:

• Documenti parziali rimasti dopo le migrazioni
• Sottodomini utilizzati erroneamente al posto del dominio principale 

Errore 2: superamento del limite di 10 ricerche DNS

Quando il controllo SPF supera le 10 ricerche DNS, si interrompe immediatamente e restituisce un PermError. Ciò invalida l'SPF per tutti i mittenti, anche quelli legittimi.

Perché succede:

• L'uso eccessivo di includono: per più strumenti SaaS
• Inclusioni annidate dai provider (tu li includi, loro ne includono altri)
• Mancanza di visibilità sul numero cumulativo di ricerche

Come risolvere il problema:

• Identificare ogni meccanismo e il suo impatto sulla ricerca
• Elimina innanzitutto i file di inclusione inutilizzati o ridondanti
• Valuta nuovamente se ogni strumento debba effettivamente inviare messaggi dal tuo dominio

Da tenere d'occhio:

• Riferimenti "nascosti" all'interno di file di inclusione di terze parti
• Un ampliamento graduale nel tempo, man mano che vengono aggiunti nuovi strumenti

Errore n. 3: Utilizzare +all (passa tutto)

Questo indica esplicitamente ai server destinatari di considerare attendibili tutte le fonti di invio, disattivando di fatto l'SPF come misura di sicurezza.

Perché succede:

• Errata interpretazione della sintassi SPF
• Le configurazioni di test temporanee non sono mai state ripristinate

Come risolvere il problema:

• Sostituisci con ~tutto durante la verifica della configurazione
• Vai a -tutti una volta confermati tutti i mittenti legittimi

Da tenere d'occhio:

• Vecchi documenti copiati da fonti inaffidabili
• Domini che sembrano "autenticati" ma che in realtà non offrono alcuna protezione

Errore 4: Utilizzo del puntatore ptr obsoleto

Meccanismi come ptr introducono ricerche lente e inaffidabili e potrebbero essere ignorati dai moderni destinatari, portando a risultati SPF incoerenti.

Perché succede:

• Configurazioni preesistenti mantenute nel tempo
• Documentazione o modelli obsoleti

Come risolvere il problema:

• Eliminare i meccanismi obsoleti come ptr
• Sostituire con include: oppure ip4: / ip6: voci

Da tenere d'occhio:

• Record eccessivamente elaborati nel tentativo di gestire casi limite
• Meccanismi che aumentano la complessità senza apportare chiari benefici

Errore n. 5: Mancanza di mittenti legittimi

Le e-mail provenienti da piattaforme valide non superano il controllo SPF, il che può comportare:

• Messaggi che finiscono nella cartella dello spam
• Ritardi nella consegna o rifiuti
• Errori DMARC se non esiste un fallback allineato

Perché succede:

• Nuovi strumenti aggiunti senza aggiornare l'SPF
• Mancanza di coordinamento tra i team che gestiscono i sistemi di posta elettronica

Come risolvere il problema:

• Tenere un elenco centralizzato di tutte le fonti di invio approvate
• Includere l'SPF nel processo di onboarding, non solo quando si presentano dei problemi
• Verificare periodicamente che tutti i mittenti attivi siano coperti

Da tenere d'occhio:

• I sistemi transazionali (fatturazione, avvisi) vengono spesso trascurati
• Strumenti regionali o specifici per le squadre che inviano autonomamente

Errore 6: record SPF che supera i 255 caratteri in una singola stringa DNS

I record SPF che superano i limiti DNS o sono formattati in modo errato potrebbero essere troncati o interpretati in modo errato, causando errori silenziosi.

Perché succede:

• Troppi "include" e meccanismi in un singolo record
• I provider DNS gestiscono i valori TXT lunghi in modo diverso

Come risolvere il problema:

• Cerca di essere il più conciso possibile
• Se necessario, è possibile inserire più stringhe tra virgolette all'interno di un singolo record TXT
• Controlla nuovamente il record pubblicato dopo averlo salvato (non solo i dati inseriti)

Da tenere d'occhio:

• Record che nel pannello DNS sembrano corretti ma non vengono risolti correttamente
• Problemi di formattazione causati dalle modifiche manuali

Esegui un controllo gratuito dello stato di SPF per verificare se il tuo record presenta uno di questi errori

Migliori pratiche SPF per il 2026

Un record SPF corretto non è solo una questione di sintassi. Si tratta piuttosto di mantenere una politica che rimanga accurata man mano che la vostra infrastruttura di posta elettronica si evolve. Queste best practice contribuiscono a garantire che la vostra configurazione SPF rimanga affidabile, efficiente e in linea con i moderni requisiti dei mittenti.

1. Mantenere un unico record SPF per dominio

SPF ammette un solo record TXT che inizi con v=spf1. La presenza di più record causa un PermError, interrompendo completamente l'autenticazione. Unisci sempre le nuove voci al tuo record esistente.

2. Includere tutte le fonti di invio legittime

Il record SPF deve includere tutti i sistemi che inviano e-mail per conto tuo. L'omissione di un mittente comporta errori SPF, con ripercussioni dirette sulla deliverability e sull'allineamento DMARC.

3. Non superare il limite di 10 ricerche DNS

Tra questi includere:, un, mx, esiste:, e redirect= viene conteggiato ai fini del limite. Il superamento di 10 comporta un PermError, invalidando l'SPF per tutte le e-mail. Controlla e ottimizza regolarmente il tuo record.

4. Rimuovere i file di inclusione inutilizzati o obsoleti

Strumenti obsoleti, ambienti di test e servizi non più in uso spesso rimangono nei record SPF anche molto tempo dopo che hanno smesso di inviare dati. Ciò aggiunge una complessità superflua e consuma il budget a disposizione per le ricerche.

5. Preferire ip4: e ip6: per un'infrastruttura controllata

Se gestisci indirizzi IP dedicati o intervalli di invio stabili, utilizza meccanismi basati su IP diretti anziché includere:. Ciò riduce le ricerche DNS e migliora le prestazioni.

6. Evita di usare +tutto in nessuna circostanza

Il +all permette a qualsiasi server di inviare messaggi a nome del proprio dominio, disabilitando di fatto l'SPF come controllo di sicurezza. Non dovrebbe mai essere utilizzato in produzione.

7. Usa ~tutte durante la configurazione, quindi passare a -all

Inizia con ~tutti (softfail) durante la convalida della configurazione. Una volta che tutti i mittenti legittimi sono stati confermati e allineati con DMARC, passa a -all (hardfail) per un'applicazione rigorosa.

8. Evita meccanismi obsoleti o rischiosi come ptr

Il ptr è deprecato e inaffidabile. Introduce ricerche DNS non necessarie e potrebbe essere ignorato dai ricevitori moderni. Utilizza invece meccanismi espliciti.

9. Monitorare le prestazioni dell'SPF tramite i rapporti DMARC

L'SPF di per sé non offre visibilità. Attiva i report DMARC per monitorare quali sorgenti superano o falliscono il controllo SPF su tutti i destinatari e individuare attività non autorizzate.

10. Considerare l'SPF come un sistema gestito in modo continuativo

L'SPF non è una configurazione che si effettua una volta sola. Ogni nuovo strumento, piattaforma o fornitore che invia e-mail deve essere indicato nel record SPF. Controllalo e aggiornalo regolarmente per evitare errori invisibili.

Come funziona l'SPF con DKIM e DMARC

SPF, DKIM e DMARC sono stati progettati per funzionare come un sistema coordinato. Ciascuno di essi affronta un aspetto diverso del problema dell'affidabilità delle e-mail, tra cui la legittimità del mittente, l'integrità del messaggio e la corrispondenza delle identità, e solo insieme garantiscono una protezione e un'applicazione affidabili.

Quando si riceve un'e-mail, l'autenticazione avviene a più livelli:

• SPF verifica se l'indirizzo IP del server mittente è autorizzato per il dominio indicato nel campo Return-Path (mittente dell'involucro)
• DKIM verifica la firma crittografica allegata al messaggio, confermando che non è stato alterato e che il dominio firmatario è valido
• DMARC valuta i risultati di SPF e DKIM e verifica se uno dei due corrisponde all'indirizzo "Da" visibile

SPF e DKIM generano risultati di autenticazione grezzi, ma è DMARC a stabilire se tali risultati siano significativi nel contesto di ciò che il destinatario vede effettivamente.

Sono necessari sia SPF che DKIM perché ciascuno di essi compensa i punti deboli dell'altro. SPF smette di funzionare in caso di inoltro, mentre DKIM continua a funzionare. DKIM può essere rimosso da alcuni intermediari, mentre SPF non dipende dal contenuto del messaggio. Insieme, garantiscono una ridondanza.

DMARC aggiunge il livello delle politiche: cosa devono fare i destinatari quando sia SPF che DKIM non superano la verifica di allineamento? Le tre opzioni sono nessuna (solo monitoraggio), messa in quarantena (inviare nella cartella spam) e rifiuto (blocco totale). DMARC aggiunge anche la funzione di segnalazione: senza di essa, non si saprebbe mai quando l'autenticazione fallisce.

Conclusione

L'SPF è alla base dell'autenticazione delle e-mail, ma la sua efficacia dipende dalla configurazione e la sua utilità dal framework DMARC a cui fa riferimento. Un record SPF configurato in modo errato compromette la consegna delle e-mail, espone il dominio al rischio di spoofing e rende l'organizzazione non conforme agli attuali requisiti per i mittenti.

Il passo successivo è lo stesso sia che tu stia configurando l'SPF per la prima volta, sia che tu stia risolvendo un problema con un record non funzionante: controlla la tua configurazione attuale.

Verifica la configurazione dell'autenticazione e-mail del tuo dominio con il nostro Domain Analyzer gratuito . Valuta SPF, DKIM, DMARC e altro in pochi secondi. Hai bisogno di monitoraggio continuo, gestione automatizzata dell'SPF e reportistica DMARC? 

Inizia una prova gratuita di 15 giorni

Domande frequenti

Un dominio può avere più di un record SPF?

No. La RFC 7208 richiede esattamente un record SPF per dominio. Se sono presenti due record TXT che iniziano con v=spf1 , entrambi restituiscono PermError e l'SPF fallisce completamente. Unisci tutte le fonti autorizzate in un unico record.

Cosa significa se il mio dominio ha troppe ricerche DNS?

Il tuo record SPF supera il limite di 10 ricerche DNS stabilito dalla RFC 7208. Ciò causa un errore SPF PermError, che impedisce l'autenticazione SPF per tutte le e-mail, non solo per quelle in eccesso. Riduci il numero di inclusioni, sostituendo con ip4:/ip6:, oppure usa l'appiattimento SPF o le macro per rimanere entro il limite.

Qual è la differenza tra SPF softfail (~all) e hardfail (-all)?

Softfail (~all) indica ai destinatari di accettare l'e-mail ma di contrassegnarla come sospetta. Hardfail (-all) indica ai destinatari di rifiutare immediatamente l'e-mail. Utilizza softfail durante la configurazione iniziale e i test; passa a hardfail una volta che tutti i mittenti legittimi sono stati confermati e DMARC è attivo.

L'SPF impedisce lo spoofing delle e-mail?

Non da solo. L'SPF verifica il mittente dell'involucro (Return-Path), non l'intestazione "Da" che vedono i destinatari. Un malintenzionato può superare il controllo SPF falsificando l'indirizzo "Da" visibile. Per impedire la falsificazione del nome visualizzato è necessario il DMARC, che verifica la corrispondenza tra i risultati di SPF/DKIM e l'intestazione "Da".

Cosa succede quando l'SPF non funziona?

Dipende dal qualificatore SPF e dal fatto che DMARC sia configurato. Con -all e una politica di rifiuto DMARC, l'e-mail viene bloccata. Con ~all e senza DMARC, l'e-mail potrebbe comunque essere recapitata ma contrassegnata come sospetta. Senza alcun SPF, i destinatari non hanno alcun segnale SPF da valutare.

Come posso controllare il mio record SPF?

Usa uno strumento gratuito strumento di ricerca SPF. Inserisci il tuo dominio e lo strumento recupererà il tuo record SPF dal DNS, ne verificherà la sintassi, conterà le ricerche DNS e segnalerà eventuali errori, incluse le violazioni PermError e void lookup.

Mi serve l'SPF se ho già DKIM e DMARC?

Sì. DMARC richiede che almeno uno tra SPF e DKIM superi il controllo e sia allineato. Sebbene DKIM da solo sia sufficiente per soddisfare i requisiti di DMARC, l'utilizzo sia di SPF che di DKIM garantisce una maggiore ridondanza. Se uno dei due fallisce (ad esempio, se SPF non funziona in caso di inoltro), l'altro può comunque superare il controllo di allineamento DMARC.

Cos'è l'allineamento SPF?

L'allineamento SPF indica che il dominio presente nel campo Return-Path (mittente dell'involucro) corrisponde al dominio nell'intestazione From. DMARC verifica tale allineamento. In assenza di tale allineamento, l'SPF può risultare valido ma DMARC continuerà a dare esito negativo – ed è proprio ciò che accade con molti mittenti di terze parti, a meno che non siano configurati per utilizzare il tuo dominio nel campo Return-Path.

Con quale frequenza dovrei aggiornare il mio record SPF?

Controlla il tuo record SPF ogni volta che aggiungi o rimuovi un servizio di invio e verifica la sua validità almeno una volta al trimestre. I record SPF perdono validità man mano che i fornitori modificano gli intervalli IP e lo stack di invio della tua organizzazione si evolve. Un record SPF che era valido sei mesi fa potrebbe oggi risultare non funzionante o incompleto.

Che cos'è l'appiattimento SPF?

L'appiattimento SPF risolve tutti include: meccanismi in indirizzi IP grezzi, riducendo il numero di ricerche DNS. Questo ti permette di rimanere al di sotto del limite di 10 ricerche, ma crea un record statico che deve essere aggiornato ogni volta che un fornitore cambia i propri IP. Alternative moderne come le macro SPF mantengono il record dinamico pur rimanendo al di sotto del limite.

• Informazioni su
• Ultimi messaggi

Ahona Rudra

Esperto di sicurezza dei domini e della posta elettronica presso PowerDMARC

Ahona è la Marketing Manager di PowerDMARC, con oltre 5 anni di esperienza nella scrittura di argomenti di cybersecurity, specializzata in sicurezza dei domini e delle e-mail. Ahona ha conseguito una laurea in Giornalismo e Comunicazione, consolidando la sua carriera nel settore della sicurezza dal 2019.

Ultimi messaggi di Ahona Rudra (vedi tutti)

• Caso di studio DMARC MSP: The Great Geek amplia i servizi di sicurezza e-mail per le PMI con PowerDMARC - 25 giugno 2026
• Come funziona lo spoofing delle e-mail come servizio (Email Spoofing-as-a-Service) e come contrastarlo - 24 giugno 2026
• Ricognizione per il phishing: come gli autori degli attacchi individuano e prendono di mira i domini vulnerabili - 24 giugno 2026