Defaults.Exposed › Correzioni › Guides

SPF PermError: come risolvere "Too Many DNS Lookups" senza rompere la sua email (2026)

Pubblicato 2026-07-08

Dati aggiornati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini valutati. Veda come assegniamo i voti.

Almeno 797.263 domini superano il limite SPF dei 10 lookup DNS, secondo il censimento Defaults.Exposed di 261.086.232 domini — su 139 milioni di domini che pubblicano SPF. Oltre i dieci lookup il ricevente si ferma e restituisce PermError: il suo SPF è nullo, e il DMARC conta un PermError come un fallimento.

La soluzione ha un ordine rigoroso, e la maggior parte delle guide lo prende al contrario. Conti i suoi lookup reali, risolti; elimini gli include morti e inutilizzati — questo da solo sistema la maggior parte dei record; sposti gli invii massivi su sottodomini con il proprio budget SPF; appiattisca solo come ultima risorsa, e solo con ri-appiattimento automatizzato, perché l’appiattimento statico marcisce e rompe la consegna in silenzio.

Cosa significa “SPF PermError: too many DNS lookups”?

L’RFC 7208 §4.6.4 limita ogni verifica SPF a 10 lookup DNS. Oltre i dieci, il ricevente si ferma e restituisce PermError — l’intero record viene trattato come rotto, non solo la parte oltre il budget. La stessa sezione aggiunge un secondo tetto meno noto: al massimo 2 “void lookup” (interrogazioni che non restituiscono risposta o NXDOMAIN), quindi un paio di voci include: morte per servizi dismessi possono annullare da sole il suo SPF.

La conseguenza è peggiore di “nessun SPF”: il DMARC tratta un PermError come un fallimento SPF, quindi un dominio che rompe il proprio SPF risulta non autenticato sulla gamba SPF di ogni valutazione DMARC. Se il DKIM non è configurato o si rompe in transito, quella posta ora fallisce il DMARC del tutto.

Un numero del censimento mostra quanto sia crudele questa modalità di guasto: 112.215 domini pubblicano un record rigoroso -all che è nullo per sforamento dei lookup — sui 54.655.923 domini che pubblicano -all in assoluto. I loro titolari hanno fatto la parte difficile — hanno scelto la chiusura rigorosa — e un include di troppo ha spento l’intero record. Sembrano rigorosi; sono rotti. Per il quadro completo dei dati, veda il report sul PermError SPF.

Perché il mio SPF si è rotto se non ho cambiato nulla?

Perché il budget viene speso in gran parte dai record di altri. Ogni include: viene valutato in modo ricorsivo, e ogni meccanismo di lookup al suo interno conta contro i suoi dieci. Una sola riga nel suo pannello DNS può costare quattro o cinque lookup una volta risolta. Un provider annida un include in più, e il suo SPF muore senza un solo cambiamento nella sua zona.

Le grandi piattaforme non sono il problema: Google e Microsoft hanno entrambe appiattito il proprio SPF — _spf.google.com e spf.protection.outlook.com si espandono in semplici elenchi di IP che costano zero lookup interni (verificato sul DNS live, luglio 2026). Gli sforamenti reali arrivano dalle catene di include dei pannelli di hosting annidate su più livelli, e dall’onesto accumulo SaaS — casella più newsletter più CRM più helpdesk, ognuno “solo un include”. Nessuno aggiunge l’undicesimo lookup apposta; arriva come somma di decisioni ragionevoli. Ecco perché il bordo del baratro è così affollato: 2.119.539 domini si trovano esattamente a 9–10 lookup risolti — circa 1 su 66 di tutti i domini che pubblicano SPF, a posto oggi, nulli il giorno in cui qualcuno incolla un include in più. Il record SPF al 99° percentile si risolve già in 9 lookup. Se il suo stack è ricco di SaaS, la guida all’SPF che fallisce per gli strumenti SaaS copre la versione fornitore per fornitore.

Quali parti di un record SPF contano come lookup DNS?

Conti il totale risolto, non le righe visibili. Quattro include possono essere quattro lookup o quattordici.

Come risolvo “too many DNS lookups” senza rompere l’email?

1. Esegua la scansione gratuita prima di toccare il DNS. Risolve l’intera catena di include e mostra il suo conteggio reale di lookup, così sistema il problema effettivo — non il record come appare nel suo pannello. (Se dice che non ha alcun SPF, è un guasto diverso — veda “SPF record not found”.)
2. Elimini per primi gli include morti e inutilizzati. Lo strumento abbandonato nel 2023, l’include del vecchio provider sopravvissuto a una migrazione, i duplicati, qualsiasi meccanismo ptr. Gli include morti sono doppiamente tossici: bruciano budget di lookup e sono la fonte abituale dei void lookup. La maggior parte dei record fuori budget torna sotto i 10 già in questo passaggio. Se il suo record contiene ancora i meccanismi di un provider precedente, segua la guida alla pulizia post-migrazione.
3. Verifichi che ogni include rimasto serva a qualcosa. I riceventi valutano l’SPF rispetto al dominio del Return-Path (RFC5321.MailFrom), non all’intestazione From — e molti strumenti SaaS mettono nel Return-Path il proprio dominio di bounce, quindi il loro include nel suo record non fa nulla se non spendere budget. Mantenga gli include solo per i servizi che usano il suo dominio come Return-Path; per gli altri attivi invece il DKIM con dominio personalizzato del fornitore.
4. Sposti gli invii massivi su sottodomini. Le newsletter da news.yourdomain.com, la posta transazionale da mail.yourdomain.com. Ogni sottodominio riceve il proprio record SPF con un budget nuovo di 10 lookup, e un problema in un flusso smette di riversarsi sugli altri.
5. Solo a quel punto consideri l’appiattimento — e solo quello automatizzato. Veda sotto.
6. Ripeta la scansione per confermare di essere ben sotto i 10 — punti ad avere margine, non a 10 esatti, o è appena rientrato tra i 2,1 milioni di domini sul bordo del baratro. Poi affronti tutto il resto che la scansione segnala nella pagina sistemare l’SPF.

Dovrei appiattire il mio record SPF?

L’appiattimento sostituisce gli include con i blocchi ip4:/ip6: sottostanti, che costano zero lookup. Funziona — e fatto a mano, è un’interruzione di consegna a scoppio ritardato.

I provider ruotano gli IP di invio di routine e non lo annunciano a nessuno. Un elenco statico di IP è corretto il giorno in cui lo incolla e silenziosamente sbagliato nel giro di mesi — e poiché il guasto si manifesta come altre persone che non ricevono la sua posta, lo scopre tardi. Se sfoltire e usare i sottodomini la porta sotto il limite, si fermi lì; non copi mai a mano i blocchi IP di terzi nel suo record come soluzione permanente.

Domande frequenti

Un PermError SPF significa che la mia email smette di essere consegnata? Non all’istante — è questo a renderlo pericoloso. Il DMARC conta un PermError come un fallimento SPF, quindi la consegna poggia interamente sul DKIM; se il DKIM manca o si rompe in transito, sta fallendo il DMARC. Dei 139 milioni di domini con SPF nel nostro censimento (al 2026-06-29), almeno 797.263 sono in questo stato — la maggior parte senza saperlo.

Il mio record ha solo quattro include — come può superare i 10 lookup? Gli include si contano in modo ricorsivo: tutto ciò che sta dentro ogni include (e dentro i suoi include) viene addebitato al suo budget, quindi quattro righe visibili possono risolversi in quattordici lookup. Conti con uno strumento che risolve, non a occhio — risolvere le catene è il modo in cui il nostro report sul PermError ha trovato ~100× più domini rotti di quanto mostrino i conteggi superficiali.

Il mio record termina con -all — sono protetto, no? Solo se il record viene valutato. Il nostro censimento (al 2026-06-29) ha trovato 112.215 domini i cui record rigorosi -all sono nulli per sforamento dei lookup. Un qualificatore rigoroso su un record in PermError non protegge nulla.

Il limite è di 10 lookup per include o per l’intero record? Per l’intera valutazione: l’RFC 7208 §4.6.4 limita la verifica completa a 10, più al massimo 2 void lookup. Ogni sottodominio ha il proprio record e il proprio budget — ecco perché il passaggio 4 funziona.

Le voci ip4 e ip6 contano ai fini del limite? No — i meccanismi IP non costano nulla, ed è esattamente per questo che l’appiattimento riduce il conteggio.

Invii il report al titolare

Se sta sistemando questo per un cliente o per il suo datore di lavoro, concluda il lavoro con una prova. Ripeta la scansione gratuita dopo le modifiche e inoltri il report con i voti al titolare dell’azienda: linguaggio semplice, datato, PermError sparito. È il documento che servirà per il rinnovo dell’assicurazione informatica e per il prossimo questionario di sicurezza di un cliente — la differenza tra “ho cambiato qualche record DNS” e un prima-e-dopo documentato.

Controlli gratuitamente il suo dominio

Veda il suo conteggio reale di lookup risolti — e tutto il resto di SPF, DKIM e DMARC — in privato e visibile solo al titolare.

Controlli il suo dominio → · Sistemare l’SPF → · SPF che fallisce per gli strumenti SaaS → · Configurare l’SPF su GoDaddy → · Come assegniamo i voti → · Solo dati aggregati. Dati conservati ed elaborati nell’UE.