SPF flattening

L’SPF flattening è la pratica di risolvere ogni meccanismo del record SPF che richiede una ricerca DNS - include:, a, mx, ptr, exists e redirect= - fino agli indirizzi IP concreti che vi stanno dietro, per poi pubblicare tali indirizzi direttamente come voci ip4: e ip6:. Il principio è semplice: mantenere il record entro i limiti rigorosi imposti dai server riceventi, così che la posta legittima continui ad autenticarsi man mano che la Sua infrastruttura di invio cresce.

Questa pagina è il punto di riferimento per tutto ciò che riguarda l’SPF flattening. Spiega cos’è il flattening, perché il limite di 10 ricerche costringe ad affrontare il problema, come funziona il processo passo dopo passo e dove si trovano i veri compromessi e rischi. Da qui può approfondire i compiti specifici: come appiattire un record SPF, i migliori strumenti di SPF flattening, se l’SPF flattening influisce su DKIM e DMARC, come farlo su Cloudflare e il confronto tra SPF flattening e macro.

Che cos’è l’SPF flattening?

Un record SPF è un unico record TXT, che inizia con v=spf1, e indica ai server di posta riceventi quali host sono autorizzati a inviare email per il Suo dominio. Quando aggiunge un servizio - un CRM, una piattaforma di marketing, un helpdesk, un provider di email transazionali - di norma aggiunge un include: per esso. Ogni include: punta al record SPF di un altro dominio, e il ricevente deve recuperare quel record al momento della valutazione. Quei recuperi sono ricerche DNS, e si sommano in fretta.

L’SPF flattening prende tutti questi riferimenti indiretti e li pre-risolve. Invece di chiedere al ricevente di inseguire include:_spf.google.com attraverso i record _netblocks annidati, un record appiattito elenca semplicemente gli intervalli IP sottostanti:

• Prima: v=spf1 include:sendgrid.net include:_spf.google.com a mx -all
• Dopo: v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all

Al momento della valutazione il ricevente non deve più eseguire la ricorsione tra gli include né risolvere gli obiettivi A/MX - confronta semplicemente l’IP che si connette con gli intervalli CIDR pubblicati. Ciò riduce il conteggio delle ricerche DNS a runtime praticamente a zero e mantiene il record leggero, veloce e affidabile.

“Il limite di 10 ricerche è la singola causa più comune per cui i record SPF aziendali si rompono in silenzio”, afferma Brad Slavin, General Manager di DuoCircle e fondatore di AutoSPF. “Nella nostra esperienza di gestione dell’SPF per oltre 2.000 domini di clienti, la modalità di errore è sempre la stessa: un team aggiunge un nuovo strumento SaaS, il suo include spinge il totale oltre 10, e la posta legittima inizia a fallire - ma nessuno se ne accorge finché un cliente non si lamenta di fatture o reimpostazioni di password mancanti.”

Perché il limite di 10 ricerche DNS costringe al flattening

Secondo l’RFC 7208, la valutazione SPF è limitata a 10 ricerche di meccanismi DNS e 2 ricerche a vuoto (void lookup) per controllo. Superare uno dei due limiti produce un PermError - un errore permanente che comunica ai server riceventi che la Sua email non può essere autenticata. Il server non riprova e non valuta il resto del record. Si ferma semplicemente, e ogni messaggio dal Suo dominio fallisce l’SPF.

L’insidia è che questo limite è invisibile finché non lo si supera. Una piccola azienda che invia tramite un solo provider non lo raggiungerà mai. Ma gli stack di posta moderni impilano abitualmente più ESP, un CRM, un servizio di assistenza e la posta interna - e ciascuno aggiunge una o più ricerche. Google Workspace da solo consuma circa quattro delle Sue dieci ricerche attraverso i suoi include annidati. Aggiunga Salesforce, Mailchimp, SendGrid e Zendesk e può facilmente arrivare a dodici o quindici. L’undicesima ricerca non viene mai valutata, quindi qualunque servizio si trovi oltre quel punto perde silenziosamente l’autorizzazione.

Ecco quali meccanismi contano:

Attiva una ricerca DNS	Non attiva una ricerca
include:example.com	ip4:x.x.x.x[/CIDR]
a, a:example.com	ip6:…
mx, mx:example.com	all
ptr (sconsigliato dall’RFC 7208)
exists:domain
redirect=example.com

Poiché i meccanismi ip4: e ip6: non richiedono alcuna risoluzione, il flattening scambia ogni meccanismo basato su ricerca con meccanismi che non ne richiedono. È questo l’intero meccanismo con cui il flattening La mantiene conforme. Un modo rapido per capire a che punto si trova oggi è analizzare il Suo dominio con lo SPF Checker, che espande ogni include e conta le Sue ricerche.

Perché il flattening conta per la deliverability e la sicurezza

Il limite di 10 ricerche non è solo una nota tecnica a piè di pagina - si trova direttamente sul percorso tra la Sua posta e la casella di posta in arrivo.

Deliverability. Il DMARC si basa su SPF e DKIM. Se il Suo record SPF restituisce un PermError, il DMARC lo considera un fallimento, e la posta legittima può essere messa in quarantena o rifiutata. Dal 2024, Google, Yahoo e Microsoft richiedono ai mittenti massivi di autenticarsi con SPF, DKIM e DMARC, e ora rifiutano del tutto i messaggi non conformi anziché instradarli nello spam. Insieme, questi provider coprono circa il 90% di una tipica lista di consumatori, quindi un singolo record fuori limite può interrompere la consegna alla maggior parte del Suo pubblico in un colpo solo.

Sicurezza. Quando l’SPF fallisce, i server riceventi perdono la capacità di distinguere la Sua posta legittima dai messaggi contraffatti. È esattamente questa la lacuna che il phishing e la compromissione della posta aziendale (BEC) sfruttano. Mantenere l’SPF valido - ed entro il limite - preserva il segnale di autenticazione che La distingue da un aggressore che impersona il Suo dominio.

Gestibilità. Man mano che il Suo marchio cresce, cresce anche l’elenco delle piattaforme che inviano per Suo conto. Il flattening riduce una catena sconfinata di include in un unico elenco pulito di intervalli IP, facile da leggere, controllare e comprendere.

Come funziona l’SPF flattening, passo dopo passo

Che venga eseguito manualmente o tramite automazione, il flattening segue la stessa pipeline:

1. Scoperta. Legga il Suo attuale record SPF TXT e identifichi ogni meccanismo che attiva una ricerca - include, a, mx, exists, redirect.
2. Risoluzione ricorsiva. Segua ogni catena di include, recuperando il record SPF di destinazione e proseguendo la ricorsione finché tutto il contenuto a monte è noto. Risolva gli obiettivi a/mx nei loro record A/AAAA per raccogliere sia gli indirizzi IPv4 sia IPv6.
3. Deduplica e comprimi. Unisca gli intervalli sovrapposti e aggreghi i blocchi contigui in notazione CIDR affinché il record resti compatto.
4. Pubblica. Riscriva il record come v=spf1 ip4:… ip6:… -all, rispettando il limite di 255 caratteri per stringa TXT (suddiviso in più stringhe concatenate se necessario), e aggiorni il Suo DNS.
5. Convalida. Confermi la sintassi, verifichi che il conteggio delle ricerche sia 0-1 e invii posta di prova per confermare SPF=pass e DMARC=pass.

Per la guida completa con i comandi e le specificità dei provider DNS, veda come appiattire un record SPF.

Il rovescio della medaglia: un record appiattito non è una soluzione definitiva

Il flattening risolve il problema delle ricerche, ma ne introduce uno nuovo. Quando sostituisce un include: dinamico con IP statici, si assume la responsabilità di mantenere quegli IP aggiornati. I provider ruotano costantemente la loro infrastruttura di invio e raramente La avvisano quando lo fanno.

“L’idea sbagliata sull’SPF flattening è che sia una soluzione definitiva”, afferma Adam Lundrigan, CTO di DuoCircle e architetto del motore di flattening di AutoSPF. “Gli intervalli IP dei fornitori cambiano di continuo - Google ha ruotato i suoi _netblocks tre volte solo nel 2025. Un record appiattito che non viene ri-risolto automaticamente diventa obsoleto e de-autorizza in silenzio i mittenti legittimi. Ecco perché AutoSPF esegue una nuova scansione ogni 15 minuti.”

Questa è la cosa più importante da capire sul flattening. Un record appiattito costruito a mano è accurato il giorno in cui lo pubblica e va lentamente fuori uso in seguito. Quando un provider aggiunge un nuovo intervallo IP, la posta proveniente da quell’intervallo inizia a fallire l’SPF - e poiché il fallimento è silenzioso, di solito lo scopre da una fattura respinta o da una reimpostazione di password mancata, non da un avviso. Nella telemetria di AutoSPF su 1.200 domini, il flattening ha ridotto i tassi di PermError del 93% e migliorato i tassi di successo DMARC del 7-12% nei primi 30 giorni - ma solo quando il record veniva mantenuto aggiornato. Il turnover mediano degli IP degli ESP si attesta su 2-4 modifiche a settimana per i provider ad alto volume.

Gli altri compromessi da pianificare:

• Dimensione del record. Il flattening può spingere un record TXT verso i limiti di dimensione del DNS. Punti a mantenere le risposte sotto circa 1.000-1.200 byte per evitare frammentazione e troncamento UDP, e preferisca intervalli CIDR aggregati piuttosto che enumerare i singoli indirizzi.
• Sovra-autorizzazione. Alcuni include autorizzano una porzione di internet molto più ampia di quella che effettivamente utilizza. Controllare e ridurre prima di appiattire mantiene ridotta la Sua superficie di attacco.

Manuale, tramite script o automatizzato?

Esistono tre modi per eseguire il flattening, con profili di rischio molto diversi:

• Manuale. Interroghi ogni include per i suoi IP attuali, li aggreghi e li pubblichi a mano. Gratuito e completamente sotto il Suo controllo, ma laborioso e soggetto a obsolescenza nel momento in cui un provider cambia gli IP. Pratico solo per ambienti piccoli e statici.
• Tramite script. Uno script Python o Go esegue la ricorsione sugli include, risolve A/MX, unisce gli intervalli CIDR e li invia al DNS tramite API secondo una pianificazione. Ripetibile e verificabile, ma è Lei a doversi occupare dei casi limite, della protezione dai loop e dell’affidabilità continua.
• Servizio automatizzato (dinamico). Un servizio ospitato ri-risolve continuamente i Suoi include, rileva le modifiche degli IP e ripubblica automaticamente. Ciò elimina del tutto l’onere di manutenzione, al costo di una dipendenza gestita.

Per qualsiasi organizzazione che utilizzi provider dinamici come Google Workspace, Microsoft 365, SendGrid o Amazon SES, un approccio automatizzato è fortemente preferibile - l’intera difficoltà del flattening consiste nello stare al passo con il turnover, ed è esattamente ciò di cui si occupa l’automazione. Un confronto completo delle opzioni si trova in migliori strumenti di SPF flattening.

Dove si colloca AutoSPF

Il servizio di SPF flattening automatico di AutoSPF è progettato appositamente per il problema di manutenzione che rende rischioso il flattening. Scopre ed espande i Suoi include annidati, risolve le intere catene A/MX/AAAA, deduplica e comprime gli intervalli in blocchi CIDR minimi e pubblica un record appiattito convalidato e consapevole delle dimensioni, che resta sotto il limite di 10 ricerche.

Due elementi lo distinguono:

• Esegue una nuova scansione ogni 15 minuti e aggiorna automaticamente il Suo record nel momento in cui gli IP di un provider a monte cambiano - così un record appiattito non diventa mai obsoleto in silenzio.
• Risolve esattamente agli stessi IP a cui si risolvono i Suoi include - nessun intervallo ampio ed eccessivamente permissivo e nessuna sovra-autorizzazione. Il Suo record appiattito autorizza precisamente gli host che i Suoi include reali autorizzano, e nulla di più.

Oltre a ciò, offre record con controllo delle versioni e rollback con un clic, pubblicazione canary/staging e avvisi di deriva quando la posta arriva da IP esterni al Suo set appiattito attuale. Si integra direttamente con i principali provider DNS, tra cui Route 53, Cloudflare, Google Cloud DNS e Azure DNS. Prima e dopo qualsiasi modifica, può confermare che il record si risolva correttamente con lo SPF Checker.

Flattening tra provider DNS e su larga scala

I meccanismi del flattening sono gli stessi ovunque, ma la pubblicazione varia da piattaforma a piattaforma. Su Cloudflare, per esempio, gestisce il record TXT tramite la dashboard o l’API e deve rispettarne il comportamento di suddivisione delle stringhe - i dettagli sono trattati in SPF flattening su Cloudflare.

Su scala SaaS - migliaia di tenant, flussi di invio multipli - lo schema vincente è a livelli: segmenti i flussi di posta su sottodomini (per esempio mkt.example.com per il marketing, tx.example.com per il transazionale), centralizzi la policy con redirect= verso un piccolo record canonico, appiattisca completamente i provider ad alto turnover in set ip4/ip6 aggregati e automatizzi l’aggiornamento con pubblicazione basata su diff, così che i record invariati non causino mai turnover DNS. Delegare i mittenti pesanti a sottodomini mantiene inoltre snello il Suo dominio organizzativo e semplifica l’allineamento DMARC.

Il flattening cambia DKIM o DMARC?

Il flattening cambia soltanto il modo in cui i mittenti autorizzati sono espressi nell’SPF - ip4/ip6 invece di include - non la Sua identità di dominio né le Sue firme DKIM. Finché l’SPF appiattito è pubblicato sul dominio usato nel Suo MAIL FROM/Return-Path, l’allineamento DMARC non è influenzato, e, eliminando il PermError, di solito migliora i tassi di successo DMARC quando l’SPF è l’identificatore allineato. L’intera relazione, incluso il modo in cui il DKIM spesso porta l’allineamento per i mittenti massivi, è trattata in l’SPF flattening influisce su DKIM e DMARC.

Flattening vs macro SPF

Il flattening tradizionale pre-risolve gli include in IP statici, ed è per questo che necessita di un aggiornamento costante. Le macro SPF seguono una strada diversa: usano l’espansione dinamica affinché un singolo record possa autorizzare un numero di mittenti di fatto illimitato senza mai raggiungere il limite di 10 ricerche - al costo di una maggiore complessità e di un supporto più debole da parte dei resolver. Quale approccio faccia al caso Suo dipende dalla Sua infrastruttura e dalla Sua propensione alla manutenzione; l’analisi completa è in SPF flattening vs macro.

Domande frequenti

Che cos’è l’SPF flattening in parole semplici?

L’SPF flattening è il processo di sostituzione dei meccanismi include:, a e mx nel Suo record SPF con gli indirizzi IP effettivi a cui si risolvono. Ciò fornisce ai server di posta riceventi un elenco già pronto di IP autorizzati invece di costringerli a eseguire ricerche DNS, mantenendo così il Suo record entro il limite di 10 ricerche definito dall’RFC 7208 e prevenendo i fallimenti di autenticazione.

Perché l’SPF flattening è necessario?

Il flattening diventa necessario quando il Suo dominio supera il limite di 10 ricerche DNS per valutazione previsto dalla specifica SPF. Una volta superato quel limite, l’SPF restituisce un PermError e ogni messaggio dal Suo dominio fallisce l’autenticazione, cosa che può anche causare il fallimento del DMARC. Poiché la maggior parte delle organizzazioni utilizza diversi mittenti di terze parti che aggiungono ciascuno degli include, i domini in crescita raggiungono rapidamente il tetto e necessitano del flattening per restare conformi.

L’SPF flattening migliora la deliverability delle email?

Sì. Eliminando le condizioni di PermError e TempError causate da troppe ricerche o da include a monte lenti, il flattening mantiene l’SPF in stato di superamento in modo affidabile. Nei dati dei clienti AutoSPF, passare da 12-18 ricerche a un record completamente appiattito ha ridotto i fallimenti DMARC legati all’SPF di oltre l’80% e migliorato il posizionamento nella casella di posta per la posta di marketing del 10-15% durante gli invii di picco.

Con quale frequenza va aggiornato un record SPF appiattito?

Con la stessa frequenza con cui i Suoi provider cambiano gli IP. Gli ESP ad alto turnover come SendGrid e Mailchimp meritano aggiornamenti ogni 12-24 ore, le suite stabili come Google Workspace e Microsoft 365 quotidianamente, e gli intervalli statici self-hosted settimanalmente. Un record mantenuto a mano quasi sempre diventa obsoleto - AutoSPF aggira questo problema eseguendo una nuova scansione ogni 15 minuti e ripubblicando automaticamente ogni volta che un intervallo a monte cambia.

L’SPF flattening manuale è sicuro?

Il flattening manuale è sicuro solo per ambienti piccoli e statici in cui gli IP di invio cambiano raramente. Per qualsiasi dominio che utilizzi provider dinamici, un record costruito a mano diventa obsoleto non appena un provider ruota la propria infrastruttura, de-autorizzando in silenzio i mittenti legittimi. Il flattening automatizzato è fortemente preferibile a qualsiasi scala reale, perché stare al passo con il turnover dei provider è la parte difficile.

Dovrei usare -all o ~all dopo il flattening?

Usi -all (hard fail) quando è certo che il Suo elenco appiattito sia completo e attivamente monitorato, poiché offre ai riceventi il segnale più chiaro per rifiutare la posta contraffatta. Usi ~all (soft fail) durante il lancio o mentre sta ancora aggiungendo mittenti di frequente. Una buona prassi è mantenere ~all finché i report DMARC non mostrano una finestra di superamento pulita, per poi passare a -all.