The SPF lookup limit
SPF caps the number of DNS lookups a record may trigger at 10.
Cross it and evaluation returns a permerror. Here is
exactly what counts and how to stay within budget.
SPF is validated by counting DNS-lookup-causing mechanisms. Per RFC 7208 §4.6.4, evaluating a record may trigger at most 10 of these:
includeamxptr(deprecated — avoid)existsredirect
ip4:, ip6:, all, and exp do
not count. Crucially, each include can contain its own nested
includes, and every lookup in that tree counts — so a handful of legitimate
providers compounds past 10 fast. There is also a separate limit of 2 “void”
lookups (mechanisms that resolve to nothing); exceeding either produces a
permerror.
What counts, and what doesn’t
| Counts toward the limit | Does NOT count |
|---|---|
include | ip4: |
a | ip6: |
mx | all |
ptr (deprecated) | exp |
exists | the v=spf1 tag |
redirect |
Key subtlety: the count is recursive. An include that points to
a record containing three more includes costs four lookups, not one. An mx
mechanism also costs extra when the MX has many hosts.
The void-lookup limit
Separately, a record may trigger at most 2 void lookups — mechanisms
that return no answer (NXDOMAIN or no records). A typo’d or decommissioned include can
quietly burn your void budget and cause a permerror even when your total is under
10.
How to check your lookup count
You can’t eyeball it, because the cost is hidden inside nested provider records. An SPF lookup checker expands the whole tree and reports your real total plus the per-sender breakdown.
How to stay under the limit
The three ways to fix too many SPF lookups
There are only three real strategies for getting an over-limit SPF record back under 10 lookups. Each has trade-offs:
1. Prune
Remove senders you no longer use — a self-referential
include of your own domain, a dead GoDaddy or 1&1 host, an old
marketing tool. Free and zero-maintenance, but it only works if
your real, active senders already fit inside 10 lookups.
2. Flatten
Replace each include: with the actual ip4: and
ip6: ranges it resolves to. IP mechanisms don’t count against
the limit, so a flattened record can hold unlimited senders in
zero lookups. The catch: it’s a static snapshot
— when a provider changes its sending IPs, a hand-flattened record silently
breaks mail until someone updates it.
3. Macros / exists
A single exists: mechanism (1 lookup) that checks the sending IP
dynamically against a DNS zone. Unlimited senders, one lookup, and it
updates itself when providers change — the modern, self-healing fix.
This is what a managed SPF service automates.
The practical takeaway: pruning is great when it’s enough. Beyond that, static flattening trades one silent-failure mode for another, which is why the reliable answer for most domains is a managed, self-healing record — flattening (or macros) kept continuously in sync so it never goes stale.
Frequently asked questions
What is the SPF DNS lookup limit?
Does ip4 count toward the SPF lookup limit?
ip4:, ip6:, all, and exp do not count. Only include, a, mx, ptr, exists, and redirect do.What happens if I exceed 10 lookups?
permerror, which receivers treat as a failed SPF result, hurting deliverability and DMARC.