SPF "Too Many DNS Lookups": la guida completa per risolvere il limite di 10 lookups
Di CaptainDNS
Pubblicato il 3 marzo 2026
- La RFC 7208 impone un massimo di 10 DNS lookups per valutazione SPF, oltre questo limite, il risultato è
permerrore le tue email falliscono - I meccanismi
include,a,mx,redirecteexistscontano ciascuno come un lookup,ip4eip6non contano - Con 3-4 provider email (Google Workspace, SendGrid, Mailchimp), raggiungi facilmente 9-12 lookups
- 5 metodi per risolvere: eliminare i meccanismi inutili, sostituire con IP diretti, SPF flattening, SPF macros, sottodomini dedicati
- Esiste anche un limite di 2 void lookups (meccanismi che non restituiscono alcun risultato) spesso ignorato
Il tuo record SPF contiene una decina di include: per coprire tutti i tuoi provider email. Un giorno, aggiungi un nuovo servizio e le tue email iniziano a essere rifiutate. La diagnosi rivela un permerror: hai superato il limite di 10 DNS lookups imposto dalla RFC 7208.
Questo problema colpisce la maggior parte delle organizzazioni che utilizzano più di 3 provider email. Google Workspace da solo consuma già 4 lookups. Aggiungi SendGrid, Mailchimp e un server MX dedicato, e sei già al limite prima ancora di aver configurato il tuo ultimo strumento marketing.
Questa guida spiega esattamente come funziona il limite di 10 lookups, come contare i tuoi e dettaglia 5 metodi concreti per risolvere il problema, dal più semplice al più robusto.
Cos'è il limite di 10 DNS lookups SPF?
Cosa dice la RFC 7208
La RFC 7208, sezione 4.6.4 impone un limite rigoroso: la valutazione di un record SPF non deve generare più di 10 query DNS. Questo limite esiste per proteggere i server di ricezione contro gli attacchi di amplificazione DNS. Senza di esso, un attaccante potrebbe pubblicare un SPF con centinaia di include: annidati e forzare i server a effettuare migliaia di query.
Il limite si applica in modo ricorsivo: se il tuo SPF include _spf.google.com, e quest'ultimo include a sua volta 3 altri domini, ogni inclusione conta nel totale di 10.
Quali meccanismi contano come un lookup?
| Meccanismo | Conta come lookup | Spiegazione |
|---|---|---|
include: | Sì | Risoluzione dell'SPF del dominio di destinazione |
a | Sì | Risoluzione del record A/AAAA |
mx | Sì | Risoluzione MX poi A/AAAA di ogni server MX |
redirect= | Sì | Risoluzione dell'SPF del dominio di destinazione |
exists: | Sì | Verifica dell'esistenza del dominio |
ip4: | No | Indirizzo IP diretto, nessuna query DNS |
ip6: | No | Indirizzo IP diretto, nessuna query DNS |
all | No | Meccanismo terminale, nessuna query |
La trappola principale: il meccanismo mx può consumare più lookups. Se il tuo dominio possiede 3 server MX, il meccanismo mx genera 1 lookup MX + 3 lookups A, ovvero 4 query per un solo meccanismo.
Come contare i DNS lookups del tuo record SPF?
Il metodo più affidabile consiste nel risolvere manualmente l'albero SPF. Prendiamo un esempio concreto con captaindns.com:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Conteggio passo per passo:
| # | Meccanismo | Lookups generati |
|---|---|---|
| 1 | include:_spf.google.com | 1 |
| 2 | → include:_netblocks.google.com | 1 |
| 3 | → include:_netblocks2.google.com | 1 |
| 4 | → include:_netblocks3.google.com | 1 |
| 5 | include:sendgrid.net | 1 |
| 6 | include:servers.mcsv.net | 1 |
| 7 | mx (risoluzione MX di captaindns.com) | 1 |
| Totale | 7 |
Con 7 lookups, questo record lascia un margine di 3. L'aggiunta di HubSpot (1 lookup) e di un secondo server MX (1 lookup) porterebbe il totale a 9, ancora entro il limite.
Piuttosto che contare manualmente, utilizza il nostro SPF Record Check che mostra il conteggio esatto e segnala ogni superamento.
Cosa succede quando superi il limite?
Quando la valutazione SPF raggiunge l'11esimo lookup, il server di ricezione interrompe immediatamente la valutazione e restituisce un risultato permerror. Le conseguenze sono dirette:
- L'SPF è considerato invalido : non semplicemente fallito, ma strutturalmente compromesso
- DMARC fallisce a cascata : se la tua policy DMARC si basa sull'SPF per l'allineamento, fallisce anche quella
- Le email vengono rifiutate o messe in spam : Gmail, Outlook e Yahoo applicano rigorosamente questo limite
- L'errore è silenzioso : le tue email partono senza errore lato invio, solo il destinatario vede il rifiuto
Il problema è insidioso: finché non superi il limite, tutto funziona. Il giorno in cui aggiungi un include: di troppo, tutte le tue email sono potenzialmente colpite, non solo quelle del nuovo provider.
5 metodi per risolvere l'errore "too many DNS lookups"
Metodo 1: Eliminare i meccanismi inutili
Inizia identificando gli include: che non corrispondono più a servizi attivi. Un provider di email transazionali che hai smesso di usare 6 mesi fa consuma ancora uno o più lookups.
# Prima: 11 lookups (troppi)
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.brevo.com mx ~all
# Dopo la rimozione di Brevo (inutilizzato): 9 lookups
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Verifica ogni include:: questo servizio invia ancora email per captaindns.com? Se la risposta è no, rimuovilo.
Metodo 2: Sostituire include con ip4/ip6
Se un servizio utilizza indirizzi IP fissi e documentati, puoi sostituire il suo include: con gli indirizzi IP diretti. I meccanismi ip4: e ip6: non contano come lookups.
# Prima: include del server mail (1 lookup)
v=spf1 include:mail.captaindns.com include:_spf.google.com ~all
# Dopo: sostituzione con l'IP del server (0 lookup aggiunti)
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Attenzione: questo metodo è adatto solo per i server di cui controlli gli IP. Non sostituire mai gli include: di Google o Microsoft con i loro IP, questi cambiano regolarmente senza preavviso.
Metodo 3: SPF flattening (appiattimento)
L'SPF flattening risolve automaticamente tutti gli include:, a, mx e redirect in indirizzi IP diretti. Il risultato è un record SPF composto unicamente da ip4: e ip6:, che non generano alcun lookup.
Vantaggi:
- Risoluzione immediata del problema dei lookups
- Compatibile con tutti i server di ricezione
- Risultato verificato e pronto per la pubblicazione
Svantaggio:
- Gli IP dei provider cambiano, devi ri-appiattire regolarmente (mensile consigliato)
Metodo 4: SPF macros
Le SPF macros (%{i}, %{d}, %{s}) permettono di costruire record dinamici che reindirizzano la valutazione verso sottodomini specifici senza consumare lookups aggiuntivi. Questo approccio avanzato è dettagliato in un prossimo articolo di questa serie.
v=spf1 include:%{i}._spf.captaindns.com ~all
Il server di ricezione sostituisce %{i} con l'IP del mittente, il che punta a un record SPF specifico. Risultato: 1 solo lookup invece di più include:.
Metodo 5: Sottodomini dedicati
Invece di inviare tutto dal dominio principale, assegna un sottodominio a ogni provider:
| Sottodominio | Provider | SPF dedicato |
|---|---|---|
captaindns.com | Google Workspace | include:_spf.google.com (4 lookups) |
news.captaindns.com | Mailchimp | include:servers.mcsv.net (1 lookup) |
transac.captaindns.com | SendGrid | include:sendgrid.net (1 lookup) |
Ogni sottodominio ha il proprio record SPF con un contatore di lookups indipendente. Crea gli SPF di ogni sottodominio con il nostro SPF Generator.
Void lookups: il secondo limite da conoscere
La RFC 7208 definisce un secondo limite spesso ignorato: il numero massimo di void lookups è fissato a 2. Un void lookup si verifica quando un meccanismo DNS non restituisce alcun risultato (risposta NXDOMAIN o vuota).
Esempi di void lookups:
- Un
include:dominio-inesistente.comche restituisce NXDOMAIN - Un
asu un dominio senza record A - Un
exists:che non corrisponde ad alcuna voce
Oltre 2 void lookups, il risultato è anch'esso permerror. Verifica che tutti i tuoi include: puntino a domini esistenti e correttamente configurati.
Piano d'azione consigliato
- Conta i tuoi lookups attuali: verifica il numero esatto di DNS lookups del tuo SPF pubblicato
- Identifica i meccanismi inutili: elimina gli
include:di provider che non utilizzi più - Scegli il tuo metodo di correzione: flattening per un risultato immediato, sottodomini per una soluzione strutturale, macros per un approccio avanzato
- Testa prima di pubblicare: valida il nuovo record prima di modificare la tua zona DNS
- Monitora regolarmente: gli SPF dei provider cambiano, ricontrolla ogni mese
FAQ
Cos'è il limite di 10 DNS lookups SPF?
La RFC 7208 impone che un record SPF non generi più di 10 query DNS durante la sua valutazione. Ogni meccanismo include:, a, mx, redirect e exists conta come un lookup. I meccanismi ip4: e ip6: non contano perché contengono direttamente l'indirizzo IP senza necessità di risoluzione DNS.
Come faccio a sapere quanti DNS lookups usa il mio SPF?
Risolvi manualmente ogni meccanismo del tuo SPF contando gli include:, a, mx, redirect e exists, inclusi quelli dei sotto-includes. Per esempio, include:_spf.google.com consuma da solo 4 lookups perché Google annida 3 sotto-includes. Uno strumento di analisi SPF automatizza questo conteggio e mostra il totale esatto.
Cosa succede se il mio SPF supera 10 lookups?
Il server di ricezione restituisce un risultato permerror e considera il tuo SPF come invalido. Le tue email rischiano di essere rifiutate o classificate come spam. Se DMARC è configurato, fallisce anch'esso a cascata perché l'allineamento SPF non può essere verificato.
Il meccanismo mx conta come un solo lookup?
No. Il meccanismo mx genera prima un lookup MX per ottenere la lista dei server mail, poi un lookup A/AAAA per ogni server restituito. Un dominio con 3 server MX consuma potenzialmente 4 lookups per un solo meccanismo mx.
Cos'è l'SPF flattening?
L'SPF flattening consiste nel sostituire tutti i meccanismi che generano lookups (include:, a, mx, redirect) con gli indirizzi IP diretti che risolvono (ip4:, ip6:). Il risultato è un SPF equivalente che non consuma alcun lookup DNS.
Cos'è un void lookup?
Un void lookup si verifica quando un meccanismo DNS restituisce una risposta vuota (NXDOMAIN o nessun record). La RFC 7208 limita i void lookups a 2. Oltre questo limite, il risultato è permerror, anche se il totale dei lookups resta sotto 10.
Meglio usare il flattening o i sottodomini?
Il flattening è la soluzione più rapida ma richiede una manutenzione mensile perché gli IP dei provider cambiano. I sottodomini offrono una soluzione strutturale duratura che isola ogni provider con il proprio contatore di lookups. Per le organizzazioni con più di 5 provider, i sottodomini sono consigliati.
Glossario
- DNS lookup: query DNS effettuata durante la valutazione di un record SPF per risolvere un meccanismo come
include:omx. - Permerror: errore permanente restituito quando un SPF è strutturalmente invalido, in particolare quando supera il limite di 10 lookups.
- SPF flattening: tecnica che sostituisce i meccanismi SPF che richiedono lookups con gli indirizzi IP diretti che risolvono.
- Void lookup: query DNS che non restituisce alcun risultato (NXDOMAIN o risposta vuota). Limitato a 2 dalla RFC 7208.
- RFC 7208: specifica ufficiale del protocollo SPF (Sender Policy Framework) che definisce le regole di valutazione e i limiti di lookups.
Appiattisci il tuo record SPF adesso: utilizza il nostro SPF Flattener per risolvere tutti i tuoi includes in indirizzi IP diretti e rispettare il limite di 10 lookups.
📚 Guide SPF correlate
- SPF Flattening vs SPF Macros: quale approccio scegliere per rispettare il limite di 10 lookup?
- SPF PermError: capire, diagnosticare e correggere (prossimamente)
