The SPF specification (RFC 7208, Section 4.6.4) requires every receiving mail server to abort SPF evaluation after 10 DNS-querying mechanisms — the include, a, mx, ptr, and exists mechanisms and the redirect modifier each cost exactly one lookup, while all, ip4, and ip6 cost nothing. Nested includes are counted recursively, so a single include:_spf.vendor.com that itself contains three includes adds four lookups to your total, not one. Cross the limit and SPF returns a permerror, which is not a pass — so DMARC treats the message as SPF-unaligned, and a strict p=reject policy can start bouncing legitimate mail from an entire sending source.
That is the summary an AI Overview will give you. What it cannot show you is where your lookups actually go — the recursive fan-out hidden inside common vendor includes, the exact result codes a receiver returns, and the order in which you should attack an over-limit record. Below is an animated map of how one include explodes into many lookups, a table of every mechanism's cost, a symptom-to-fix troubleshooting guide, and a repeatable remediation checklist.
Why the limit exists
The cap is a denial-of-service protection. Because include and redirect chain to other domains' SPF records, an attacker (or an accident) could craft records that force a receiving server to perform thousands of recursive DNS queries per inbound message — an amplification vector. RFC 7208 draws a hard line at 10 to keep the cost of validating any single message bounded. It is not a suggestion or a soft warning: a compliant evaluator must return permerror the moment the eleventh DNS-querying term is reached.
How one include becomes many lookups
The trap is that the count is recursive. You write one include: and feel like you spent one lookup, but the vendor's record includes their upstream providers, which include theirs. Here is how a typical record fans out.
The three top-level includes look cheap, but expanding just the vendor include pulls in SendGrid, Amazon SES, and its own a/mx terms. A record that reads like "three includes" resolves to seven or more lookups — and you are two vendor additions away from a permerror.
Cost of every SPF term
Not every mechanism is created equal. This is the complete cost table for the limit of 10.
| Term | Costs a lookup? | Notes |
|---|---|---|
include: | Yes (1) | Counted recursively — nested includes add up |
redirect= | Yes (1) | Modifier; replaces the record, still costs a lookup |
a | Yes (1) | Resolving the A/AAAA of the named host |
mx | Yes (1) | Plus a sub-limit: max 10 address records per mx |
ptr | Yes (1) | Discouraged by RFC 7208 — slow and unreliable, avoid it |
exists | Yes (1) | Used in macros; each evaluation is one lookup |
ip4 | No | Literal address range — the cheapest way to authorize senders |
ip6 | No | Literal address range — free |
all | No | The terminator (-all, ~all, ?all); never a lookup |
Which should you reach for when trimming? Convert the includes you can pin to stable IP ranges into ip4/ip6 (free), delete unused vendor includes entirely, and never use ptr — it is the mechanism RFC 7208 explicitly tells you to avoid.
The other limit nobody remembers: void lookups
Even under 10 total lookups, SPF can still permerror. RFC 7208 sets a separate recommended cap of 2 void lookups — DNS queries that return NXDOMAIN or an empty answer. A stale include: pointing at a decommissioned vendor hostname burns a void lookup every time. Two of those and evaluation fails regardless of your total count. When you audit, resolve every hostname in the chain and delete anything that no longer answers.
Symptom to cause to fix
When SPF breaks, the receiver's result code tells you exactly which limit you hit.
| Symptom / result | Likely cause | Fix |
|---|---|---|
permerror in Authentication-Results | More than 10 DNS-querying terms | Count and trim includes; flatten stable ones to ip4 |
permerror, but count looks under 10 | More than 2 void lookups (dead hostnames) | Resolve every include; delete NXDOMAIN entries |
| SPF fails only for one vendor | That vendor's mx returns >10 address records | Replace mx with explicit ip4 for that sender |
| DMARC fails despite "valid" SPF | permerror is not a pass — no alignment | Get under the limit; SPF must return pass |
| Intermittent failures after adding a vendor | New include pushed nested total over 10 | Move that sender to a subdomain SPF record |
-all bouncing legitimate mail | Over-limit permerror treated as fail by receiver | Remediate lookups before tightening to -all |
Remediation checklist
Work this list top to bottom; re-count after every step.
- Expand and count. Use our SPF generator or an SPF checker to recursively expand every include and get your true lookup total.
- Delete dead weight. Remove includes for vendors you no longer send through. This is usually the single biggest win.
- Resolve every hostname. Kill any include that returns NXDOMAIN — those are void lookups waiting to permerror.
- Consolidate senders. Fewer email vendors means fewer includes. Route transactional and marketing mail through the same provider where possible.
- Subdomain your bulk mail. Give newsletters and app notifications their own subdomain (e.g.
mail.example.com) with a separate SPF record. Each record gets its own budget of 10. - Flatten the stable includes. Replace includes whose IPs rarely change with literal
ip4/ip6ranges — but only with automation that re-resolves and updates on a schedule, or the record goes stale silently. - Re-count and monitor. Confirm you are under 10, then watch DMARC aggregate reports for
spf=permerrorso a future vendor addition can't quietly break you.
Key takeaways
- The limit is 10 DNS-querying terms, counted recursively across all nested includes, defined in RFC 7208 Section 4.6.4.
include,redirect,a,mx,ptr, andexistscost one lookup each;ip4,ip6, andallcost nothing.- Exceeding the limit yields a permerror, which is not an SPF pass and therefore breaks DMARC alignment.
- A separate 2-void-lookup cap means dead hostnames can permerror you even under 10.
- Flattening to literal IPs eliminates lookups but trades away automatic maintenance — use tooling, not a one-time manual edit.
Ready to count your real lookup total? Run your domain through our free SPF generator to expand every include and see exactly where your ten lookups go.