Come appiattire un record SPF

Appiattire un record SPF significa sostituire i meccanismi che attivano ricerche DNS — include:, a, mx, exists, ptr e redirect — con gli intervalli espliciti ip4: e ip6: a cui si risolvono. Il risultato è un record che autorizza esattamente gli stessi mittenti ma costringe i server riceventi a percorrere molte meno interrogazioni DNS (idealmente zero), mantenendoLa al sicuro sotto il limite di 10 ricerche dell’RFC 7208. Questa guida illustra il processo passo dopo passo, mostra l’aspetto di un record appiattito e spiega come mantenerlo accurato una volta attivo.

Questa pagina fa parte della nostra guida più ampia all’SPF flattening. Se vuole saltare del tutto il lavoro manuale, lo SPF Checker espande ogni include e conta le Sue ricerche in pochi secondi.

Perché appiattire un record SPF in primo luogo

L’autenticazione SPF è limitata a 10 ricerche DNS per valutazione secondo l’RFC 7208. Ogni termine include:, a, mx, exists e redirect grava su quel budget, e ciascuno può attivare ulteriori ricerche ricorsive all’interno del dominio a cui punta. Aggiunga una piattaforma di marketing, un CRM, un helpdesk e un servizio di fatturazione, e un singolo record v=spf1 può gonfiarsi silenziosamente a 15-40 ricerche.

Quando supera il limite, i riceventi restituiscono un PermError. Un PermError non fa fallire solo un messaggio — invalida l’intero record, quindi la posta legittima da ogni fonte autorizzata può iniziare a fallire l’SPF. Poiché nulla viene respinto in modo evidente, i team spesso non se ne accorgono finché un cliente non segnala una fattura o un’email di reimpostazione password mancante.

Il flattening risolve tutto ciò risolvendo quei meccanismi indiretti in anticipo e pubblicando gli IP grezzi. Un ricevente che valuta un record completamente appiattito esegue un semplice confronto di IP senza traversata DNS ricorsiva, il che significa anche una convalida più rapida e nessuna esposizione a un’interruzione temporanea del DNS di terze parti.

Come appare un record SPF appiattito

Ecco un tipico record non appiattito che si appoggia su tre include:

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

Ogni include vale almeno una ricerca, e il solo include di Google ne annida diversi altri. Appiattita, la stessa autorizzazione diventa un elenco diretto di IP:

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

Nessuna ricerca avviene al momento della valutazione perché ogni indirizzo autorizzato è già esplicitato. Il qualificatore -all è conservato affinché la policy resti rigorosa.

Come appiattire un record SPF, passo dopo passo

Passo 1: Trovi e verifichi il Suo record attuale

Estragga il Suo record SPF esistente con una query dig TXT yourdomain.com (o dalla dashboard del Suo provider DNS) e confermi di avere esattamente un record TXT v=spf1. Più record SPF sullo stesso nome sono di per sé un PermError. Annoti quali meccanismi causano ricerche (include, a, mx, exists, redirect, ptr) rispetto alle voci ip4/ip6 senza costo che può mantenere così come sono.

Passo 2: Conti le Sue ricerche

Prima di modificare qualsiasi cosa, misuri di quanto ha superato il budget. Analizzi il Suo dominio con lo SPF Checker, che espande ricorsivamente ogni include e Le fornisce un conteggio esatto delle ricerche. Se è a 8 o più, o vede già un PermError, il flattening (o la delega) è giustificato. Se è a 3 o meno include stabili, potrebbe non aver bisogno di appiattire affatto.

Passo 3: Risolva ricorsivamente ogni meccanismo in IP

Questo è il cuore del flattening. Per ogni termine che causa una ricerca, lo risolva fino agli indirizzi espliciti:

Meccanismo	Come risolverlo	Risultato
include:	Recuperi il record SPF di destinazione ed espanda ricorsivamente i suoi meccanismi	ip4:/ip6: per ogni IP che autorizza
a	Risolva i record A/AAAA del dominio	Un ip4:/ip6: per indirizzo
mx	Risolva i record MX, poi gli A/AAAA di ogni host di posta	ip4:/ip6: per l’IP di ciascun host MX
ptr	Non appiattisca — è deprecato, lento e inaffidabile	Lo rimuova
exists:	Di solito non appiattibile (dipende da macro a runtime)	Lo mantenga così com’è o lo isoli su un sottodominio
ip4/ip6	Già statico	Lo mantenga invariato

Percorra il grafo in modalità depth-first e tenga traccia dei domini già visitati per poter rilevare gli include circolari — se un include punta di nuovo a un dominio già presente nello stack di risoluzione, si fermi e lo mantenga come include invece di andare in loop all’infinito.

Passo 4: Deduplichi e aggreghi i CIDR

L’espansione ricorsiva produce sovrapposizioni. Due fornitori possono condividere un IP, oppure può raccogliere diversi blocchi /25 adiacenti che si combinano ordinatamente in un /24. Deduplichi ogni indirizzo, poi aggreghi gli intervalli adiacenti in supernet solo quando l’unione resta interamente all’interno dello spazio autorizzato di un unico provider. Aggregare eccessivamente tra provider non correlati autorizza IP che non controlla — una regressione di sicurezza, non un’ottimizzazione.

Passo 5: Controlli la dimensione del record

Le stringhe TXT del DNS sono limitate a 255 caratteri per segmento tra virgolette; i record più lunghi devono essere suddivisi in più stringhe concatenate all’interno dello stesso record. Come regola pratica, mantenga la risposta totale sotto circa 450-900 byte per evitare frammentazione UDP e problemi con i middlebox. Se l’elenco appiattito è troppo grande, suddivida gli IP in etichette di supporto (per esempio spf-a.example.com, spf-b.example.com) che contengano ciascuna solo voci ip4/ip6 e le includa dal record principale — ogni etichetta di supporto costa una ricerca, quindi mantenga il totale ≤ 10.

Passo 6: Riattacchi il qualificatore all e convalidi

Aggiunga il Suo meccanismo di terminazione originale — -all per un’applicazione rigorosa è consigliato per i mittenti in produzione. Poi ripassi il record attraverso un validatore SPF per confermare che la sintassi sia pulita, che ci sia ancora un solo record e che il conteggio delle ricerche sia dove se lo aspetta. Se sta migrando con cautela, può pubblicare con ~all per un breve periodo, poi passare a -all una volta che il monitoraggio mostra tassi di superamento stabili.

Passo 7: Pubblichi con un TTL basso, poi lo aumenti

Prima di pubblicare, abbassi il TTL del record a 60-300 secondi affinché qualsiasi errore possa essere corretto rapidamente. Pubblichi il nuovo record appiattito, verifichi che si risolva correttamente da più resolver pubblici (Google, Cloudflare, Quad9) e monitori i Suoi report aggregati DMARC per eventuali cali nei tassi di superamento SPF. Una volta che tutto è stabile, riporti il TTL a 1-4 ore.

Il rovescio della medaglia: i record appiattiti diventano obsoleti

Ecco il problema che coglie in fallo la maggior parte di chi appiattisce a mano. Nel momento in cui appiattisce, il Suo record è un’istantanea. Quando Google, Mailchimp, Amazon SES o qualsiasi altro provider ruota i propri IP di invio — e i grandi ESP lo fanno di continuo — il Suo elenco fisso non corrisponde più alla realtà. La posta dai nuovi IP fallisce silenziosamente l’SPF, e si ritrova alle fatture perse e alle reimpostazioni di password fallite, solo che ora la causa è invisibile perché il record sembra a posto.

I mittenti supportati da CDN e quelli di marketing sono i peggiori: i dati interni di AutoSPF su oltre 1.200 domini mostrano che i mittenti supportati da CDN ruotano l’8-15% del loro set di IP ogni mese, contro meno dello 0,5% dei server di posta interni. Appiattire alla cieca un provider ad alto turnover significa cercare guai.

Le indicazioni pratiche:

• Appiattisca le fonti stabili (relay on-prem, IP cloud statici) in modo aggressivo.
• Lasci gli ESP volatili come include, oppure li isoli dietro un sottodominio delegato come mail-out.example.com che la radice include con una singola ricerca.
• Non tratti mai il flattening come un’operazione una tantum — necessita di ri-risoluzione continua.

Automatizzi il ri-flattening con AutoSPF

Eseguire i passi 1-7 a mano ogni volta che un fornitore cambia gli IP non è realistico. È esattamente ciò per cui è costruito il servizio di SPF flattening automatizzato di AutoSPF. Esegue continuamente l’algoritmo di flattening deterministico descritto sopra: riesegue la scansione dei Suoi include ogni 15 minuti e, quando gli IP di un provider a monte cambiano, aggiorna automaticamente il Suo record pubblicato tramite l’API del Suo provider DNS — con scambi atomici, TTL scaglionati e rollback con un clic in caso di fallimento di un controllo canary.

Aspetto cruciale, AutoSPF risolve esattamente agli stessi IP a cui si risolvono i Suoi include — non allarga mai l’autorizzazione con fusioni CIDR troppo ampie, quindi non autorizza accidentalmente mittenti che non intendeva autorizzare. Lei mantiene un record piccolo e stabile alla radice; AutoSPF lo tiene corretto in background.

Per decidere quali delle Sue fonti appiattire rispetto a delegare, veda la nostra guida sui migliori strumenti di SPF flattening. Se preferisce evitare del tutto di fissare gli IP, confronti gli approcci in SPF flattening vs macro. E prima di appiattire, vale la pena confermare che la modifica non disturbi gli altri record di autenticazione — veda l’SPF flattening influisce su DKIM e DMARC.

Domande frequenti

Appiattire un record SPF rompe DKIM o DMARC?

No, se fatto correttamente. Il flattening cambia solo quali IP l’SPF autorizza — non tocca le firme DKIM né l’allineamento DMARC. Il rischio è indiretto: se un record appiattito obsoleto inizia a far fallire l’SPF per la posta legittima, ciò può abbassare i tassi di superamento DMARC. Mantenga il record ri-risolto ed entrambi resteranno in salute.

Quante ricerche DNS usa un record SPF appiattito?

Un record completamente appiattito usa zero ricerche DNS al momento della valutazione, perché ogni IP autorizzato è elencato esplicitamente come ip4:/ip6:. Se mantiene alcuni include volatili o suddivide gli IP in etichette di supporto, ciascuna di esse aggiunge una ricerca — basta mantenere il totale pari o inferiore al limite di 10 dell’RFC 7208.

Posso appiattire i meccanismi ptr ed exists?

In genere no. Il ptr è deprecato, lento e andrebbe semplicemente rimosso. L’exists: di norma si basa su macro a runtime (che valutano MAIL FROM o HELO al momento del controllo), quindi non può essere ridotto a un elenco statico di IP. Mantenga exists così com’è, oppure lo isoli su un sottodominio delegato per limitarne l’impatto sulle ricerche.

Con quale frequenza va aggiornato un record SPF appiattito?

Con la stessa frequenza con cui i Suoi mittenti cambiano gli IP. I server di posta interni possono essere stabili per settimane, ma i principali ESP e le CDN possono cambiare indirizzi quotidianamente. Ecco perché il flattening manuale è fragile e AutoSPF riesegue la scansione ogni 15 minuti, pubblicando automaticamente un record aggiornato ogni volta che un set di IP a monte cambia.

Cosa succede se il mio record appiattito diventa troppo grande?

I record TXT del DNS sono limitati a 255 caratteri per stringa, e i record sovradimensionati rischiano la frammentazione UDP. Se l’elenco di IP appiattito è troppo grande, lo suddivida in etichette di supporto (ciascuna contenente solo voci ip4/ip6) e le includa dal record principale, oppure deleghi i provider volatili a un sottodominio. Punti a mantenere la risposta totale sotto ~900 byte e le ricerche ≤ 10.

Dovrei appiattire il mio record SPF manualmente o usare uno strumento?

Il flattening manuale funziona per una correzione una tantum, ma non riesce a stare al passo con i provider che ruotano gli IP — un record appiattito a mano de-autorizza in silenzio i mittenti non appena un intervallo a monte cambia. Uno strumento gestito come AutoSPF si occupa per Lei della risoluzione ricorsiva, della deduplicazione, della gestione delle dimensioni e del ri-flattening continuo, motivo per cui è l’approccio consigliato per qualsiasi cosa vada oltre un singolo mittente statico.