I punti chiave da prendere in considerazione
- SPF aiuta a verificare se un server mittente è autorizzato a inviare e-mail per conto del tuo dominio, ma funziona al meglio se utilizzato insieme a DKIM e DMARC.
- I record SPF utilizzano meccanismi, qualificatori e modificatori per definire i mittenti autorizzati e controllare il modo in cui i server di ricezione gestiscono la posta non conforme.
- Il server del destinatario controlla il record SPF tramite ricerca DNS per verificare l'autorizzazione del mittente.
- I controlli SPF possono restituire i risultati "Pass", "Fail", "SoftFail", "Neutral", "None", "TempError" o "PermError", a seconda della valutazione del record e del server ricevente.
- I modificatori SPF come exp e redirect offrono ulteriori opzioni di personalizzazione per la convalida e la gestione delle e-mail.
Se ti sei mai chiesto perché alcune delle tue e-mail legittime finiscano nella cartella dello spam o vengano bloccate del tutto, il problema potrebbe dipendere da come è configurata l’autenticazione e-mail del tuo dominio. Un fattore chiave in questo contesto è la sintassi del record SPF, che svolge un ruolo cruciale nel verificare che le tue e-mail siano inviate da server autorizzati. Sebbene l’SPF contribuisca a evitare che i tuoi messaggi vengano contrassegnati come sospetti, la sua sintassi può essere difficile da comprendere e ancora più complicata da configurare correttamente.
In questo articolo spiegheremo nel dettaglio come funziona la sintassi dei record SPF e cosa è necessario tenere presente quando li si configura per il proprio dominio.
Che cos’è la sintassi del record SPF?
La sintassi del record SPF è l'insieme delle regole che definiscono il modo in cui un record SPF (Sender Policy Framework) viene scritto nel DNS di un dominio. In parole povere, è il "linguaggio" che il dominio utilizza per indicare ai server di posta elettronica riceventi quali fonti sono autorizzate a inviare e-mail per suo conto.
La sintassi dei record SPF comprende in genere meccanismi (come ip4, ip6 o include), qualificatori (come +, -, ~ o ?) e modificatori che, agendo congiuntamente, determinano se un’e-mail in arrivo supera o meno il controllo SPF.
La comprensione di questa sintassi è fondamentale, perché anche un piccolo errore, come uno spazio in più, un qualificatore errato o un meccanismo mancante, può far fallire l'autenticazione delle e-mail e farle finire nello spam o rifiutarle.
Notasull'allineamento DMARC: SPF verifica la validità del dominio del mittente indicato nell'involucro, che non sempre corrisponde all'indirizzo "Da" visibile agli utenti nella loro casella di posta in arrivo. Affinché DMARC superi il controllo tramite SPF, il dominio presente nel campo Return-Path deve corrispondere al dominio "Da" visibile. Questo è il motivo per cui SPF dovrebbe essere utilizzato in combinazione con DKIM e DMARC.
Struttura e componenti della sintassi dei record SPF
Un record SPF è composto da quattro parti principali: il tag di versione, i meccanismi, i qualificatori e i modificatori. Ciascuna parte svolge un ruolo specifico e, nel loro insieme, determinano il modo in cui i server di posta riceventi gestiscono i messaggi che dichiarano di provenire dal proprio dominio.
| Componente SPF | Scopo | Esempio |
|---|---|---|
| Etichetta della versione | Identifica il record come SPF | v=spf1 |
| Meccanismo | Definisce i mittenti autorizzati | ip4:203.0.113.5 |
| Qualificatore | Definisce il risultato quando un meccanismo corrisponde | -tutti, ~tutti |
| Modificatore | Aggiunge istruzioni di elaborazione opzionali | redirect=, exp= |
Tag versione
Il tag di versione costituisce il punto di partenza di un record SPF. Identifica il record come scritto secondo la sintassi SPF e garantisce che i server di posta interpretino correttamente il testo che segue. Senza di esso, il record non funzionerà. È consentito un solo tag di versione, che deve apparire all’inizio del record. Formato attualmente valido: v=spf1.
Operatori di qualificazione SPF: +, -, ~ e ?
I qualificatori sono simboli inseriti prima dei meccanismi. Indicano al server di posta ricevente cosa fare se il meccanismo corrisponde. Se non viene specificato alcun qualificatore, l'azione predefinita è "Pass".
| Qualificatore | Risultato | Significato | Caso d'uso tipico | Livello di rischio |
|---|---|---|---|---|
| + | Passo | Mittente autorizzato; posta accettata | Predefinito — raramente indicato esplicitamente | Basso |
| - | Bocciatura | Mittente non autorizzato; messaggio rifiutato | Applicazione rigorosa dopo la completa implementazione | Basso se completo |
| ~ | SoftFail | Probabilmente non autorizzato; segnalato | Fase di test o implementazione transitoria | Medio |
| ? | Neutro | Nessuna decisione a livello di policy; è il server a decidere | Raramente utilizzato nella produzione | Alta — nessuna protezione |
Meccanismi SPF: all, ip4, ip6, a, mx, exists e include
I meccanismi sono le regole principali di un record SPF. Essi definiscono quali server, indirizzi IP o domini sono autorizzati a inviare posta per conto del dominio. Ogni meccanismo viene verificato in ordine da sinistra a destra e, se viene individuata una corrispondenza, viene applicato il qualificatore associato.
| Meccanismo | Esempio di sintassi | Cosa autorizza | Ricerche DNS | Uso consigliato |
|---|---|---|---|---|
| tutti | -tutti | Corrisponde a tutti i mittenti — "catch-all" alla fine | 0 | Concludi sempre con -all o ~all |
| ip4 | ip4:203.0.113.5 | Un indirizzo IPv4 specifico o un intervallo CIDR | 0 | Server dedicati per il traffico in uscita |
| ip6 | ip6:2001:db8::1 | Un indirizzo IPv6 specifico o un prefisso | 0 | Posta in uscita tramite IPv6 |
| a | a oppure a:example.com | Indirizzi IP corrispondenti ai record A/AAAA del dominio | 1 | Quando il server web invia anche e-mail |
| mx | mx | Indirizzi IP dei server MX del dominio | 1 per MX | Quando i server MX inviano messaggi in uscita |
| ptr | ptr:example.com | Verifica DNS inversa (obsoleta ai sensi della RFC 7208) | Multiplo | Da evitare — obsoleto |
| esiste | esiste:example.com | Viene superato se il dominio viene risolto nel DNS | 1 | Utilizzo avanzato con le macro |
| includere | include:_spf.google.com | Mittenti autorizzati dal dominio indicato | 1 + annidato | Mittenti di terze parti |
Il meccanismo "all": -all vs ~all vs ?all
-all (Hard Fail): Qualsiasi mittente non presente nell'elenco viene esplicitamente rifiutato. Utilizza questa opzione una volta che il tuo record SPF è stato completamente testato e tutti i mittenti legittimi sono stati inclusi. Questa è l'impostazione consigliata per un'applicazione rigorosa.
~tutti (SoftFail): I mittenti non presenti nell'elenco vengono accettati ma contrassegnati. Utilizzare questa opzione durante i test o nella fase di implementazione transitoria, quando non si è ancora certi che tutti i mittenti legittimi siano presenti nell'elenco.
?tutti (Neutro): Ai mittenti non presenti nell'elenco non viene applicata alcuna politica. Questa impostazione non offre alcuna protezione effettiva e non è consigliata per l'uso in produzione.
+all (Invia a tutti): Consente a qualsiasi server di inviare messaggi per tuo conto. Si tratta di un'opzione pericolosa che non dovrebbe mai essere utilizzata.
Modificatori SPF: redirect ed exp
redirect= (Modificatore): Delega l'intera valutazione della politica SPF a un altro dominio. A differenza di include, redirect sostituisce completamente il record corrente e non può essere combinato con un meccanismo all. Il meccanismo SPF "include" funziona in modo diverso. Aggiunge i mittenti autorizzati dal record SPF di un dominio di riferimento senza sostituire il proprio.
exp= (Modificatore): Fornisce una stringa di spiegazione personalizzata per gli errori SPF. Quando un messaggio non supera il controllo SPF, il server ricevente può consultare questo record TXT per recuperare una motivazione comprensibile all'utente.
"include" vs "redirect": differenza fondamentale
| includere | reindirizzare | |
|---|---|---|
| Tipo | Meccanismo | Modificatore |
| Effetto | Aggiunge i mittenti del dominio di riferimento | Sostituisce l'intera valutazione SPF |
| Si può usare con tutti? | Sì | No — tutte le sostituzioni reindirizzano |
| Numero di ricerche DNS | Conta ai fini del limite di 10 ricerche | Conta ai fini del limite di 10 ricerche |
Risultati della valutazione dell'SPF e loro significato
Quando un server di posta in ricezione valuta un record SPF, restituisce uno dei sette risultati possibili. Comprendere ciascun risultato aiuta i proprietari dei domini a individuare le cause degli errori di consegna e a migliorare la configurazione SPF. Per strategie su come risolvere gli errori SPF più comuni, consulta la nostra guida su come ottimizzare il proprio record SPF.
Esempi di sintassi del record SPF
Record SPF semplice
v=spf1 ip4:203.0.113.5 -all
v=spf1 → tag di versione. ip4:203.0.113.5 → autorizza un indirizzo IPv4. -all → tutti gli altri server vengono rifiutati. Si tratta di una configurazione comune per un dominio di piccole dimensioni che invia e-mail da un unico server.
Record SPF avanzato
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com
Questo record autorizza un intero intervallo IP /24, due mittenti di terze parti, accetta mittenti non presenti nell’elenco con un flag SoftFail e fornisce una spiegazione personalizzata dell’errore. Ogni meccanismo di tipo “include”, “a”, “mx”, “exists” e “redirect” attiva ricerche DNS. Se il totale supera 10, SPF restituisce un PermError.
Esempio di record SPF aziendale
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
Questo record è comune per le organizzazioni che utilizzano Google Workspace, Microsoft 365 e una piattaforma di distribuzione di terze parti. Ogni aggiunta comporta ricerche DNS, pertanto i team dovrebbero effettuare un'attenta verifica per evitare risultati di tipo PermError.
Esempio di gestione MSP SPF
Per gli MSP che gestiscono numerosi domini dei clienti, l’obiettivo non è solo quello di creare un record SPF valido, ma anche di monitorare le modifiche su tutti i clienti. La convalida centralizzata degli SPF aiuta a individuare record duplicati, rischi legati ai limiti di ricerca e inclusioni non funzionanti prima che i clienti riscontrino problemi di consegna. Il Programma Partner MSP/MSSP consente ai fornitori di servizi di gestire l’autenticazione su tutti i domini dei clienti da un’unica dashboard, senza dover cambiare strumento o analizzare manualmente i record DNS.
Esempi di sintassi dei record TXT SPF per caso d'uso
| Caso d'uso | Record TXT SPF | Spiegazione | Attenzione |
|---|---|---|---|
| Solo server MX | v=spf1 mx -all | Solo i server MX possono inviare | Dà errore se inviato tramite un server non MX |
| IPv4 singolo | v=spf1 ip4:203.0.113.5 -all | È autorizzato un indirizzo IP specifico | Aggiornamento in caso di modifica dell'IP |
| Mittenti multipli | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all | Google + Microsoft 365 | Totale delle ricerche sul monitor |
| Reindirizzamento | v=spf1 redirect=_spf.example.com | Politica delegata | Non combinare con tutti |
| Non inviare | v=spf1 -all | Dominio inattivo, nessuna e-mail | Da utilizzare esclusivamente per scopi non legati all'invio |
Come utilizzare più meccanismi di inclusione nella sintassi dei record SPF
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all
Ogni meccanismo di inclusione attiva almeno una ricerca DNS, e le inclusioni annidate ne aggiungono altre. Il totale lungo l’intera catena non deve superare 10. L’elaborazione SPF si interrompe alla prima corrispondenza, quindi l’ordine è importante: inserisci per primi i mittenti più utilizzati. Se il numero di ricerche si avvicina a 10, utilizza lo strumento di appiattimento SPF per ottimizzare automaticamente il tuo record. Per configurazioni aziendali complesse, le macro SPF offrono un’alternativa più scalabile al livellamento tradizionale, espandendosi dinamicamente al momento della valutazione.
Troppe ricerche DNS nei record SPF
La RFC 7208 limita a 10 il numero totale di ricerche DNS durante la valutazione SPF. Questo limite si applica all’intera catena di ricerca, comprese le ricerche annidate innescate dai meccanismi include, a, mx, exists e redirect. Se il limite viene superato, il server ricevente restituisce un PermError, causando il fallimento totale della verifica SPF. Esiste inoltre un vincolo meno noto: il limite di 2 ricerche nulle. Se più di due query DNS restituiscono NXDOMAIN, anche l’SPF fallisce. Per una guida dettagliata su come risolvere questo problema, consulta come risolvere il problema del numero eccessivo di ricerche DNS.
Meccanismi che contano: include (1 + annidato), a (1), mx (1 per ogni ricerca MX + A), exists (1), redirect (1 + annidato), ptr (multiplo — deprecato).
Meccanismi che NON vengono conteggiati: ip4 e ip6 non attivano le ricerche DNS.
Come ridurre le ricerche DNS: Rimuovere i meccanismi "include" per i mittenti che non si utilizzano più. Sostituire i meccanismi "a" e "mx" con valori IPv4 espliciti, ove possibile. Evitare i record "pt". Utilizzare PowerSPF (SPF ospitato) per consolidare gli "include" e rimanere entro il limite senza dover effettuare la manutenzione manuale del DNS. Per ulteriori informazioni sul processo di "flattening" stesso, consultare Appiattimento SPF: dal sovraccarico DNS a un SPF ottimizzato.
Come pubblicare un record TXT SPF nel DNS
Il record SPF viene pubblicato come record TXT nel DNS del tuo dominio a livello di dominio principale (ad es., example.com) o nel sottodominio pertinente. Utilizza il nostro generatore gratuito di record SPF per creare immediatamente un record valido prima della pubblicazione.
| Campo DNS | Valore da inserire | Note |
|---|---|---|
| Host / Nome | @ oppure spazio vuoto per il dominio principale | Utilizzare il nome del sottodominio per i record SPF del sottodominio |
| Tipo | TXT | Il tipo SPF legacy (Tipo 99) è obsoleto; utilizzare sempre il tipo TXT |
| Valore | Il tuo record SPF completo, ad esempio: v=spf1 include:_spf.google.com -all | Bisogna iniziare con v=spf1 |
| TTL | 3600 (1 ora) | Un TTL più basso accelera la propagazione durante le modifiche |
Importante: Un dominio deve avere un solo record TXT SPF. La pubblicazione di più record TXT che iniziano con v=spf1 causa un errore PermError.
Flusso di lavoro per la convalida della sintassi SPF
Fase 1: Effettuare un inventario di tutte le fonti di invio: Microsoft 365, Google Workspace, CRM, strumenti di marketing, sistemi di assistenza tecnica, sistemi di gestione delle buste paga e mittenti regionali.
Fase 2: Scrivere o aggiornare il record SPF — Aggiungere solo meccanismi e inclusioni autorizzati.
Fase 3: Verifica del numero di ricerche DNS — Assicurati che il record non superi il limite di 10 ricerche DNS.
Passaggio 4: Verifica la sintassi — Utilizza uno strumento di verifica SPF per individuare eventuali problemi di formattazione, duplicati e meccanismi obsoleti.
Passaggio 5: Monitorare i risultati dell'autenticazione — Esaminare i rapporti DMARC per verificare che i mittenti legittimi superino i controlli di allineamento SPF e DKIM.
Regole di sintassi, convalida ed errori comuni dei record SPF
La scrittura di un record SPF consiste nell'inserire i meccanismi e i qualificatori nell'ordine giusto e nell'assicurarsi che il record funzioni effettivamente come previsto. Anche piccoli errori di sintassi, come un tag mancante o uno spazio in più, possono far fallire il record, facendo sì che le e-mail vengano rifiutate, contrassegnate come spam o lasciando il vostro dominio vulnerabile allo spoofing.
Questa sezione copre tre aree chiave: le migliori pratiche per la scrittura della sintassi SPF, gli errori comuni da evitare e come convalidare il record prima di pubblicarlo.
Seguire le migliori pratiche per la sintassi SPF
Per ottenere un SPF corretto è necessario seguire alcune regole d'oro che rendono la registrazione efficace e affidabile:
- Iniziare sempre con il tag della versione corretta: v=spf1.
- Limite DNS per evitare di superare il limite di limite di 10 ricercheche causerà l'interruzione del record.
- Utilizzare l'opzione include per evitare loop o riferimenti circolari.
- Cercate di mantenere la documentazione il più concisa possibile: le configurazioni eccessivamente complesse sono più difficili da gestire e più soggette a errori.
- Rivedere regolarmente i record SPF, soprattutto se la vostra infrastruttura e-mail cambia o se aggiungete/rimuovete provider.
Gestione della sintassi SPF per MSP e MSSP
Per gli MSP e gli MSSP che gestiscono l'SPF su numerosi domini dei clienti, le best practice vanno oltre la semplice creazione di un unico record corretto. Tra le considerazioni operative fondamentali figurano:
- Standardizzare i modelli SPF per le configurazioni client più comuni (ad esempio Google Workspace + Microsoft 365) al fine di accelerare l'onboarding e ridurre gli errori di sintassi.
- Automatizzare il monitoraggio del numero di ricerche per ricevere avvisi prima che il record SPF di un cliente superi il limite di 10 ricerche DNS, specialmente quando i clienti aggiungono nuovi strumenti SaaS.
- Utilizza dashboard centralizzate per individuare contemporaneamente, su tutti i domini dei clienti, record SPF duplicati, include non funzionanti o meccanismi mancanti.
- Modifiche ai documenti ogni volta che viene aggiunto un nuovo mittente all'ambiente di un cliente, al fine di mantenere una traccia di audit accurata ai fini della conformità e della risoluzione dei problemi.
Evitare gli errori di sintassi più comuni
Molti problemi di SPF derivano da errori semplici ma dannosi. Fate attenzione a queste insidie:
- Manca il tag della versione: ogni record deve iniziare con v=spf1.
- Qualificatori duplicati: l'uso di più di un qualificatore per lo stesso meccanismo non è valido.
- Meccanismi eccessivi: record lunghi e gonfiati aumentano il rischio di errori e superano i limiti del DNS.
- Problemi di formattazione sintattica: spazi fuori posto, errori di battitura o caratteri non supportati possono causare il fallimento del record.
- Record SPF multipli: un dominio deve avere un solo record SPF: se ne esistono più di uno, la convalida fallirà.
- Meccanismi obsoleti: evitare ptr, che non è più consigliato e potrebbe non essere supportato da tutti i server.
Ricordate: anche se l'intento del record è corretto, gli errori di sintassi causano il fallimento completo dell'SPF.
Convalidare la sintassi del record SPF
Prima di pubblicare il record SPF, la convalida è fondamentale. I validatori controllano che la sintassi sia corretta e che il record non superi i limiti di ricerca DNS o contenga meccanismi non supportati.
- Utilizza strumenti di verifica dei record SPF, come quello di PowerDMARC SPF Checker, per individuare rapidamente eventuali problemi.
- La convalida aiuta a garantire che il record funzioni in modo coerente su diversi server di posta ricevuti.
- Si consiglia di testare i record nuovi o aggiornati in un ambiente di staging prima di applicarli dal vivo.
- La convalida regolare dopo le modifiche mantiene la politica SPF aggiornata e funzionale.
La convalida riduce il rischio che le e-mail vengano respinte, che finiscano nello spam o che il vostro dominio sia vulnerabile allo spoofing.
Sintassi del record SPF in azione
Una sintassi corretta dei record SPF è fondamentale per garantire la consegna sicura delle e-mail e la protezione contro lo spoofing. Ciascuna parte — tag di versione, meccanismi, qualificatori e modificatori — contribuisce a determinare il modo in cui i server di posta gestiscono i messaggi.
Con la diffusione sempre maggiore dell’SPF, la cui percentuale di superamento dei test a livello globale si attesta ora all’80,24%, le organizzazioni che investono in una sintassi SPF pulita e convalidata ottengono un vantaggio tangibile in termini di deliverability, conformità e livello di sicurezza.
Per una guida completa passo dopo passo alla procedura di configurazione iniziale, consulta come configurare i record SPF. Inoltre, per assicurarti di soddisfare i più recenti requisiti di conformità, consulta i requisiti di autenticazione delle email di Google e Yahoo per il 2026.
Domande frequenti
1. Come si scrive un record SPF?
Inizia con v=spf1, aggiungi i meccanismi per elencare i mittenti autorizzati (come ip4: per indirizzi IP specifici o include: per servizi di terze parti) e concludi con un qualificatore come -all per bloccare tutto il resto. Pubblica il record come singolo record DNS TXT nella radice del tuo dominio.
2. Cosa succede se la sintassi del mio record SPF è errata?
I server di posta potrebbero rifiutare o contrassegnare le tue e-mail come spam, e il tuo dominio diventa più vulnerabile allo spoofing. Un errore di sintassi, come l'assenza del tag di versione, la presenza di record SPF duplicati o il superamento del limite di 10 ricerche DNS, può causare il completo fallimento dell'SPF.
3. Qual è un esempio di record SPF che utilizza MX?
Un record SPF che utilizza MX ha il seguente formato: v=spf1 mx -all, il che consente solo ai server di smistamento della posta del dominio di inviare e-mail per suo conto.
4. Quante ricerche DNS sono consentite in un record SPF?
SPF consente un massimo di 10 ricerche DNS per ogni valutazione, come definito nella RFC 7208. I meccanismi che vengono conteggiati sono: include, a, mx, exists, redirect e ptr. Se tale limite viene superato, SPF restituisce un PermError.
5. È possibile avere più record SPF per un unico dominio?
No. Un dominio deve avere un solo record TXT SPF. La presenza di più record che iniziano con v=spf1 causa un PermError. Raggruppare tutti i mittenti autorizzati in un unico record.
6. Qual è la differenza tra SPF -all e ~all?
-all (rifiuto definitivo) indica ai destinatari di rifiutare i messaggi provenienti da mittenti non presenti nell'elenco. ~all (rifiuto temporaneo) indica ai destinatari di accettare i messaggi, ma di contrassegnarli. Utilizzare ~all durante la fase di test e passare a -all una volta confermati tutti i mittenti legittimi.
7. L'SPF da solo impedisce lo spoofing delle e-mail?
No. L'SPF verifica solo il mittente dell'involucro (Return-Path), non l'indirizzo "Da" visibile. Deve essere abbinato a DKIM e DMARC per garantire una protezione completa contro lo spoofing e il phishing.
8. Che cos’è l’appiattimento SPF e quando è necessario ricorrervi?
L'appiattimento SPF sostituisce i meccanismi "include" con gli indirizzi IP risolti, riducendo così il numero di ricerche DNS. È necessario quando il record SPF supera o si avvicina al limite di 10 ricerche DNS. Strumenti automatizzati come PowerSPF gestiscono questa operazione in modo dinamico.
9. Quanto tempo ci vuole perché un record SPF si propaghi?
La propagazione del DNS richiede in genere da 1 a 4 ore, a seconda del provider DNS e delle impostazioni TTL. In alcuni casi, può richiedere fino a 48 ore. Verifica sempre il tuo record dopo la pubblicazione.
- Sicurezza del fax: una guida completa alla protezione dei documenti riservati nel 2026 - 30 luglio 2026
- Che cos’è un servizio di filtraggio delle e-mail? - 29 luglio 2026
- Spoofing delle e-mail: cos’è e come contrastarlo - 29 luglio 2026