Short answer. The SPF spec (RFC 7208) allows at most 10 DNS Lookup when evaluating a record. The include, a, mx, ptr and exists mechanisms each consume the limit, and nested includes count recursively. Exceeding it returns permerror and SPF stops passing. Fix it by trimming includes, replacing them with ip4 (flattening) and removing unused services.
Why the 10-lookup limit exists
The limit protects mail servers from excessive load and DoS attacks via infinitely nested SPF records. Each DNS lookup costs time during evaluation, so the RFC caps them firmly at ten.
What consumes the limit
- include — each one, plus every lookup inside the included record.
- a and mx — one lookup each (mx also resolves every name).
- ptr — consumes the limit and is discouraged.
- exists — one lookup.
- ip4 / ip6 and all — do NOT consume the limit (static data).
How to count lookups
# A record that blows past the limit:
dig +short txt example.com
# "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org
# include:_spf.mailjet.com include:amazonses.com mx a ~all"
# Each include expands recursively:
dig +short txt _spf.google.com
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
# include:_netblocks3.google.com ~all"Ways to fix it
- Remove unused services. Every former sender in SPF is wasted lookups.
- Replace include with ip4 (flattening). Put the service's real subnets directly;
ip4does not count. - Drop ptr — slow and consumes the limit.
- Use subdomains for different mail streams to spread the load.
- Auto-flattening from SPF providers keeps the record under the limit dynamically.
| Mechanism | Counts toward limit? | Tip |
|---|---|---|
| include | Yes (recursive) | Minimize the count |
| a / mx | Yes | Replace with ip4 where possible |
| ptr | Yes | Do not use |
| ip4 / ip6 | No | Preferred flattening method |
| all | No | Always end the record with it |
Flattening speeds up checks but hardcodes IPs: if the provider changes subnets, SPF stops passing. Revisit flattened records periodically.
The limit of 10 is about nested DNS lookups, not the number of IPs. One ip4:203.0.113.0/24 covers 256 addresses and costs zero lookups.
How enterno.io helps
The /email-check tool expands all nested includes in your SPF record, counts the actual number of DNS lookups and instantly shows whether the limit of 10 is exceeded and which include is to blame. That saves hours of manually unrolling chains with dig. enterno diagnoses and advises — flattening and editing the TXT in the zone is done by the domain owner. Free: 48+ tools, a DNS check and SPF explained.
FAQ
What happens when the limit is exceeded?
SPF returns permerror and the check counts as failed. This can also break DMARC alignment via SPF and hurt deliverability.
Does ip4 count toward the 10-lookup limit?
No. ip4 and ip6 are static data with no DNS lookup. That is exactly why flattening via ip4 solves the limit problem.
Is automatic flattening safe?
It is convenient but creates a dependency on the provider keeping subnets fresh. Make sure the record syncs regularly with current IPs.
Check your limit: run /email-check and see the actual lookup count in your SPF. See also SPF syntax and why emails go to spam.