Pubblicare un record SPF non protegge nulla se lo stesso record supera una soglia che quasi nessuno controlla. La causa più frequente di un fallimento SPF raramente è la sua assenza totale. Deriva da un record mal costruito, che supera il limite di 10 richieste DNS fissato dalla RFC 7208 senza che nulla avvisi il mittente prima dell’incidente. Un record SPF valido contiene l’elenco dei server autorizzati a inviare email per un dominio; oltre le 10 richieste DNS necessarie per valutarlo, il server ricevente restituisce un errore PermError che invalida l’autenticazione per tutti i messaggi del dominio, non solo per il mittente in eccesso.
Cosa autorizza davvero un record SPF
Un record SPF (Sender Policy Framework) è un record DNS di tipo TXT pubblicato su un dominio, che elenca gli indirizzi IP autorizzati a inviare email a suo nome. Un server ricevente, Gmail o Outlook per esempio, interroga questo DNS e confronta l’IP di connessione con questa lista. L’SPF verifica il MAIL FROM, chiamato anche Return-Path: l’indirizzo tecnico dei rimbalzi e delle NDR, non l’indirizzo mostrato nel campo “Da:” del client di posta. Questa distinzione lascia una breccia aperta allo spoofing visivo.
I meccanismi che compongono il record SPF
La sintassi SPF si basa su una serie di meccanismi che, messi in fila, definiscono chi ha il diritto di inviare. ip4: e ip6: dichiarano direttamente un intervallo di indirizzi, senza interrogare il DNS una seconda volta. a e mx verificano che l’IP mittente corrisponda al record A o ai server MX del dominio citato. include: delega la verifica al record SPF di un altro dominio, tipicamente quello di un fornitore di invio (ESP, CRM, strumento di fatturazione). ptr effettua una risoluzione inversa, oggi sconsigliata dalla stessa RFC 7208 per la sua lentezza. exists verifica l’esistenza di un record A costruito dinamicamente. Il modificatore redirect, invece, non si aggiunge alla lista: sostituisce interamente la valutazione con quella di un altro record, un po’ come un redirect HTTP applicato al DNS. Ciascuno di questi meccanismi, ad eccezione di ip4 e ip6, consuma una richiesta DNS distinta al momento della valutazione. Un include: può a sua volta contenere altri include: annidati, senza che la riga visibile lo lasci intuire. Anche l’ordine di scrittura conta: il server ricevente valuta i meccanismi da sinistra a destra e si ferma al primo che corrisponde all’IP mittente. Mettere i server interni più utilizzati all’inizio del record non cambia il risultato finale. Accelera solo la valutazione sui domini con alto volume di invio.
I qualificatori -all, ~all, ?all: cosa succede a un’email non conforme
Un record SPF termina sempre con un qualificatore che stabilisce il destino di un’email inviata da un IP assente dalla lista. -all (fail strict) chiede al server ricevente di rifiutare il messaggio. ~all (softfail) chiede di accettarlo ma di contrassegnarlo come sospetto, spesso instradandolo verso lo spam. ?all (neutral) non dà alcuna indicazione chiara, il che equivale a lasciare che ogni provider di posta decida da solo. Un ultimo qualificatore, +all, autorizza esplicitamente qualsiasi IP a inviare a nome del dominio; ha senso solo per disattivare volontariamente l’SPF in fase di test, mai in produzione. Gmail e Microsoft 365 trattano il softfail con una tolleranza che diminuisce ogni anno. Un dominio ancora configurato con ~all per prudenza finisce spesso per migrare verso -all una volta che DKIM e DMARC sono in atto; senza questo passaggio, l’SPF si limita a suggerire diffidenza invece di deciderla.
Un record SPF commentato riga per riga
Prendiamo un esempio rappresentativo di un dominio che invia sia dai propri server sia tramite un ESP terzo:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx -all
v=spf1 dichiara la versione del protocollo, sempre identica. ip4:203.0.113.10 autorizza direttamente il server mail interno dell’azienda, senza costo di lookup. include:_spf.google.com delega l’autorizzazione ai server di Google Workspace, usati qui per le email dei collaboratori. include:sendgrid.net fa lo stesso per le campagne inviate tramite SendGrid. mx aggiunge automaticamente i server MX del dominio all’elenco dei mittenti validi. -all chiude il record in fail strict: qualsiasi IP assente da questa lista vede il proprio messaggio rifiutato. Questo record consuma già 3 lookup sui 10 consentiti (i due include: e il mx), senza contare che ogni include: può a sua volta innescare più sotto-richieste una volta risolto.
Il limite di 10 lookup DNS e l’errore PermError
La RFC 7208, sezione 4.6.4, fissa due soglie distinte sulla valutazione di un record SPF. La prima, la più nota, limita a 10 il numero di richieste DNS innescate dai meccanismi include, a, mx, ptr, exists e dal modificatore redirect; ip4 e ip6 non ne costano nessuna, poiché l’indirizzo è già scritto nel record. La seconda soglia, meno documentata, limita a 2 il numero di “void lookup” tollerati: una richiesta DNS che torna senza risposta (NXDOMAIN), generalmente causata da un include: che punta a un dominio scritto male o a un fornitore non più attivo il cui record è stato rimosso (AutoSPF, marzo 2026). Superare l’una o l’altra soglia produce lo stesso verdetto: PermError. Il server ricevente interrompe allora la valutazione e tratta l’autenticazione come un fallimento, per la totalità dei messaggi del dominio, compresi quelli inviati da un IP perfettamente legittimo e documentato tre righe più sopra nel record.
L’appiattimento SPF, noto anche come SPF flattening, risolve questo superamento sostituendo ogni include: con l’elenco grezzo degli indirizzi IP che designa. La valutazione costa allora un solo lookup, indipendentemente dal numero di fornitori di invio citati all’origine. Fornitori specializzati in deliverability come dmarcian o PowerDMARC documentano questa tecnica e propongono servizi che ricalcolano il record a ogni cambio di IP lato fornitore. Il procedimento ha un proprio limite: una stringa TXT DNS è limitata a 255 caratteri per segmento. Un record appiattito che elenca direttamente decine di indirizzi IP finisce a volte per avvicinarsi pericolosamente a questo limite, il che obbliga a suddividerlo in più stringhe concatenate.
Questo spiega uno scenario classico nei team growth: le campagne finiscono in spam, senza che arrivi alcuna spiegazione dal SaaS di emailing utilizzato, che pure mostra “SPF configurato”. La dashboard verifica l’esistenza e la sintassi del record. Non ricalcola mai il numero di lookup una volta risolti tutti gli include: a cascata. Un dominio che ha accumulato Google Workspace, un ESP transazionale, uno strumento di marketing automation e un CRM può superare il limite senza che nessuna di queste integrazioni, presa singolarmente, sembri esserne la causa.
Verificare il proprio record SPF prima che si rompa
Verificare il proprio record SPF non richiede strumenti a pagamento. Il metodo più diretto si svolge in tre passaggi:
- Interrogare il DNS da riga di comando con
dig txt tuodominio.com(onslookup -type=txt tuodominio.comsu Windows) per leggere il record come è realmente pubblicato, non come è stato inserito nell’interfaccia del registrar. - Passare questo record in un verificatore SPF online che risolve ogni
include:annidato e mostra il conteggio totale dei lookup, invece di contare i meccanismi a mano. - Ripetere questo controllo a ogni aggiunta di un nuovo servizio di invio (ESP, strumento di fatturazione, piattaforma di recruiting che invia email ai candidati) e non solo al momento della configurazione iniziale.
Google Postmaster Tools funge da strumento postmaster lato Gmail. Lo SNDS svolge lo stesso ruolo presso Microsoft per il monitoraggio della reputazione IP. Entrambi mostrano uno storico di autenticazione. Nessuno dei due segnala un superamento dei lookup prima che produca un PermError effettivo su un invio reale.
Il doppio record e gli errori più ricorrenti
Un dominio deve pubblicare un solo record SPF. Averne due, spesso perché un’agenzia ha aggiunto il proprio senza rimuovere quello già presente, produce un nuovo PermError: la RFC 7208 non prevede alcuna fusione automatica tra due record TXT di tipo SPF. L’altro errore ricorrente consiste nel dimenticare un fornitore di invio terzo nella lista, uno strumento di sondaggi o una piattaforma di recruiting che invia email transazionali a nome del dominio senza mai essere stato aggiunto al record. Questi messaggi falliscono silenziosamente finché un cliente non segnala di non aver ricevuto nulla.
Il forwarding delle email fa fallire l’SPF: cosa fa (e cosa non fa) SRS
Un’email inoltrata rompe quasi sempre l’SPF, per costruzione del protocollo. Il server che inoltra il messaggio non compare mai nel record SPF del dominio di origine, l’autenticazione fallisce quindi lato destinatario finale. Il Sender Rewriting Scheme (SRS) corregge questo caso specifico riscrivendo l’indirizzo MAIL FROM del messaggio con il dominio del server relay, che è invece regolarmente autorizzato nel proprio SPF (documentazione Microsoft Learn, settembre 2025). Questo meccanismo ha un punto cieco documentato dalla stessa Microsoft: l’SPF convalida allora il dominio del relay, mentre il campo “From” visibile dal destinatario continua a mostrare il dominio di origine.
La documentazione Microsoft lo precisa chiaramente: SRS non risolve il caso dei messaggi inoltrati che falliscono il DMARC, poiché questo protocollo richiede un allineamento tra il dominio convalidato da SPF (o DKIM) e il dominio mostrato nel campo From.
Un messaggio può quindi superare l’SPF grazie a SRS e fallire comunque in DMARC reject, per mancanza di allineamento tra i due domini verificati.
SPF, DKIM e l’allineamento DMARC: il meccanismo che protegge la reputazione
SPF e DKIM non parlano della stessa cosa al server ricevente. SPF convalida il MAIL FROM, DKIM firma crittograficamente l’intero messaggio. DMARC aggiunge un livello che i due protocolli ignorano da soli: l’allineamento, cioè la verifica che il dominio autenticato da SPF o DKIM corrisponda effettivamente al dominio mostrato nel campo “From” letto dall’utente. Senza questo allineamento, un messaggio può convalidare l’SPF tramite un ESP terzo pur mostrando un dominio mittente completamente diverso, esattamente lo schema di un attacco di phishing per usurpazione. Questo triplice controllo condiziona il complaint rate e la lotta contro spam e phishing sia su Gmail che su Outlook.
Un record SPF pulito non compensa una lista piena di indirizzi morti: una campagna inviata a indirizzi inesistenti fa salire il tasso di hard bounce, il che degrada la sender reputation che SPF e DKIM dovrebbero proteggere, indipendentemente dalla cura messa nella configurazione DNS. Verificare la lista prima dell’invio, una pratica di list hygiene di base, costa meno in termini di reputazione rispetto a filtrare a posteriori gli Enhanced Status Codes 5.1.1 restituiti dai server di destinazione dopo che la campagna è già partita. Il DMARC chiude il cerchio: senza di esso, SPF e DKIM restano due verifiche isolate, senza legame garantito con l’indirizzo che il destinatario guarda davvero.
Un dominio correttamente autenticato non si nota mai: non compare in nessun report di incidente, proprio perché nessuno ha bisogno di parlarne.
