Why SPF has a 10-lookup limit (and how many lookups SPF allows)
SPF allows a maximum of 10 DNS lookups per evaluation, defined by RFC 7208 to bound DNS overhead and prevent amplification abuse. Exceeding it returns a PermError that fails authentication for every message from the domain.
SPF (Sender Policy Framework) lets a receiving mail server verify that a message actually came from a server your domain authorizes. When mail arrives, the receiver fetches the SPF record published as a DNS TXT record for your domain and evaluates it against the connecting IP address. That evaluation is not free: every include:, a, mx, ptr, exists, and redirect mechanism forces the receiver to make another DNS query. To keep that work bounded, RFC 7208 caps a single SPF check at 10 DNS mechanism lookups (plus a separate limit of 2 void lookups). Exceed either and the check returns PermError, which fails authentication for every message from the domain.
This page explains exactly how many lookups SPF allows, why that number is 10, which mechanisms spend your budget, and what to do when you cross the line. For the full topic, start at the pillar guide on SPF too many DNS lookups.
How many lookups does SPF allow?
SPF allows a maximum of 10 DNS lookups per evaluation. This is a hard ceiling written into RFC 7208, and it is enforced strictly by every major inbox provider, including Gmail, Outlook/Microsoft 365, and Yahoo. There is no “warning” tier and no grace: the 11th lookup stops evaluation cold.
The count is not the number of entries you typed into your record. It is the number of DNS queries the receiver has to make to resolve those entries. That distinction is where most domains get caught, because a single include: can quietly expand into three or four lookups inside the included provider’s own record.
Two related limits sit alongside the main one:
- 10 mechanism lookups. Triggered by
include,a,mx,ptr,exists, andredirect.ip4:andip6:cost zero lookups because the IP is already in the record — nothing needs resolving. - 2 void lookups. A void lookup is a DNS query that returns an empty answer (NXDOMAIN or no records). Two of those and you also get a
PermError, even if you are under 10 mechanism lookups.
If you want to see your own number before you go further, run your domain through the SPF Checker — it expands every include and counts the queries for you. For the step-by-step method, see how to count your SPF lookups.
Why does the 10-lookup limit exist?
The limit is a resource-protection mechanism, not a security feature in itself. As Adam Lundrigan, CTO of DuoCircle, puts it: “RFC 7208 caps lookups to prevent SPF evaluation from becoming a DNS amplification vector.” Break that down and there are four practical reasons the cap is set where it is.
DNS query overhead and network latency
Every lookup is a round trip to a DNS server, and each round trip adds latency to the SMTP handshake. Without a cap, a maliciously (or carelessly) constructed record could force a receiver to make dozens of queries per message, delaying delivery. Spam filters also treat high latency as a signal of a poorly configured or malicious sender, so a bloated record can hurt deliverability independently of the SPF result.
Preventing DNS amplification and DoS abuse
An attacker can craft SPF records with recursive or excessive includes to fan a single email check out into a large burst of DNS queries. Point those responses at a victim IP and you have a denial-of-service amplifier. This is sometimes called SPF record bombing. Capping lookups at 10 removes the multiplier that makes the attack worthwhile.
Finite DNS server resources
DNS servers have limited memory, bandwidth, and processing power. Unlimited SPF resolution would let a small number of complex domains consume a disproportionate share of that capacity, degrading service for everyone.
Simplicity and predictability
A fixed, low ceiling keeps receiver-side evaluation logic simple and deterministic. Every receiver behaves the same way at the same boundary, which is far easier to reason about — and far less bug-prone — than an open-ended recursion.
Which mechanisms count toward the limit?
Understanding what spends your budget is the whole game:
| Mechanism | Counts as a lookup? |
|---|---|
include: | Yes — one, plus any nested lookups inside the included record |
a | Yes — one |
mx | Yes — one per query (and MX records that resolve to many hosts add more) |
ptr | Yes — discouraged; DNS-intensive and slow |
exists | Yes — one |
redirect= | Yes — evaluates an entire other domain’s record |
ip4: / ip6: | No — zero lookups |
all (~all, -all) | No |
The critical insight is nesting. When you add include:_spf.google.com, you are not authorizing one lookup — you are inheriting Google’s entire chain of nested includes. Microsoft 365, Mailchimp, HubSpot, and most transactional-email providers do the same. As Brad Slavin, founder of AutoSPF, notes: “A team adds a new SaaS tool, its include pushes the total past 10, and legitimate email starts failing — but nobody notices until a customer complains about missing invoices or password resets.”
What happens when you exceed 10 lookups?
The receiver stops evaluating and returns PermError (permanent error). Practically, that means:
- SPF evaluation halts before it can verify your sending IP.
- SPF is treated as a hard failure even though your record is still published in DNS and looks correct.
- Because SPF failed, DMARC alignment via SPF also fails. If DKIM is missing or misaligned too, DMARC fails outright.
- Your domain loses trust, phishing protection weakens, and legitimate mail can be rejected or filed as spam.
This is why the failure is so insidious: your record looks fine in the DNS zone, MXToolbox shows the mechanisms, and nothing throws a visible error — yet mail is silently failing. (Note the distinct cousin, TempError, which signals a transient DNS problem rather than a lookup-count violation; our fix SPF PermError guide covers both.)
Why modern companies hit the limit so fast
A few years ago most organizations sent mail from one server. Today a typical stack layers Google Workspace or Microsoft 365 for staff email, a marketing platform for campaigns, a CRM for sales, a billing system for invoices, a help desk for support, and a transactional provider for password resets and verification codes. Each asks you to add “just one include,” and each of those includes drags in its own nested chain. Three or four visible entries routinely resolve to more than 10 actual lookups. The record grows quietly until one more tool tips it over.
How to fix a record that has hit the limit
You have three broad options, in roughly increasing order of durability.
- Clean up. Remove includes for services you no longer use, and delete duplicate providers that appear under more than one entry. Every stale include still spends a lookup. See how to reduce SPF lookups for the full pruning checklist, and watch the SPF 255-character limit as your record changes.
- Flatten. Resolve each
include:,a, andmxdown to the underlyingip4:andip6:addresses, which cost zero lookups. This is the most reliable structural fix — see SPF flattening for how it works. The catch: vendors rotate their IP ranges, so a hand-flattened record goes stale and silently de-authorizes legitimate senders the moment an upstream IP changes. - Automate the flattening. This is where cleanup and flattening stop being a recurring chore.
Because manual flattening breaks the instant a provider changes IPs, the durable answer is an automatic SPF flattening service that keeps the record fresh for you. AutoSPF rescans your upstream vendor ranges every 15 minutes, resolves to the exact same IPs the upstream includes resolve to (so there is no over-authorization), de-duplicates overlapping ranges, and auto-updates your published record when anything changes. You add one include: pointing at AutoSPF and never touch the lookup count again. Premium plans add SPF macros for effectively unlimited includes.
Frequently Asked Questions
How many DNS lookups does SPF allow?
SPF allows a maximum of 10 DNS mechanism lookups per evaluation, plus a separate limit of 2 void (empty-answer) lookups. Both are defined in RFC 7208 and enforced by all major inbox providers. Crossing either returns a PermError.
Do ip4: and ip6: count toward the 10-lookup limit?
No. ip4: and ip6: mechanisms list the sending IP directly in the record, so the receiver does not need to resolve anything. They cost zero lookups, which is exactly why SPF flattening — converting includes into IP entries — brings a record back under the limit.
What error do I get when I exceed the SPF lookup limit?
You get a PermError (permanent error). SPF evaluation stops, the check is treated as a failure even though your record is still published, and DMARC alignment via SPF fails as well. Legitimate mail can then be rejected or marked as spam.
Why is the SPF limit set to 10 and not higher?
Ten balances functionality against resource protection. It bounds DNS query overhead and latency, removes the amplification multiplier that would let SPF be abused for DoS attacks, protects finite DNS server capacity, and keeps receiver-side evaluation simple and predictable.
How do I know if my record is over the limit?
Run your domain through a checker that expands nested includes and counts the actual queries — the SPF Checker does this in one click. Manual signs include intermittent SPF failures, mail landing in spam, and DMARC reports showing SPF failures despite a published record.
Does flattening permanently fix the lookup limit?
Flattening fixes it structurally, but not permanently on its own, because email providers rotate their IP ranges and a static flattened record goes stale. The lasting fix is automated flattening that rescans and re-publishes on a schedule — AutoSPF does this every 15 minutes so the record stays accurate as vendor IPs change.