Troubleshooting

SPF Lookup Limit: The 10 DNS Lookup Rule

RFC 7208 limits SPF evaluation to ten DNS lookups, and exceeding that limit causes a PermError that breaks authentication.

Intermediate · 8 min read · Reviewed Jul 4, 2026

Quick answer

RFC 7208 limits SPF to ten DNS lookups during a single evaluation, counting include, a, mx, ptr, exists, and redirect lookups. Exceeding this limit produces a PermError, meaning the SPF check cannot complete successfully. Large organizations with many ESPs often hit this ceiling and must flatten records or consolidate includes to restore reliable authentication.

Beginner explanation

SPF has a hard ceiling that surprises many teams: a receiving server may perform at most ten DNS lookups while evaluating your policy. That sounds generous until you count how many vendors, redirects, and nested includes a modern domain uses.

When the limit is exceeded, SPF does not quietly ignore the extra entries. The result is PermError, a permanent failure state that tells receivers your policy cannot be interpreted reliably. That is worse than a simple misconfiguration because it signals a broken policy architecture.

The lookup limit exists to protect mail infrastructure from slow or abusive DNS chains. Understanding it is essential for any domain that sends through more than one provider.

Technical explanation

RFC 7208 Section 4.6.4 defines the ten-lookup maximum. The initial TXT lookup for the domain's SPF record does not count toward the limit, but each subsequent DNS query triggered by mechanisms does. Nested include evaluation is especially costly because each included domain may itself contain additional includes.

A PermError result typically causes DMARC to fail when SPF is part of the alignment strategy, even if individual IP addresses would otherwise match. Some receivers treat PermError as equivalent to no useful SPF signal, which weakens spoofing protection and may reduce inbox placement for legitimate mail.

Common mitigation strategies include SPF flattening, replacing includes with explicit ip4 and ip6 ranges where feasible, removing unused provider entries, using subdomains for different sending streams, and centralizing authorization through a managed include service that keeps lookup counts predictable.

Business impact

Hitting the lookup limit undermines email authentication for the entire domain, not just mail from the newest vendor. DMARC reports may show sudden SPF failure spikes, and security teams lose confidence in anti-spoofing controls.

Marketing and IT often blame the latest integration when the real issue is cumulative policy bloat. Until the record is restructured, every sending channel sharing that SPF policy remains at risk.

Common mistakes

- Stacking five or more ESP includes without measuring total nested lookup cost
- Treating PermError as a temporary DNS glitch instead of a structural policy problem
- Adding redirect modifiers that unexpectedly pull in additional lookup chains

How SPF Manager helps

SPF Manager calculates effective lookup usage across your published record and nested dependencies. It surfaces PermError risk before you deploy DNS changes and shows which includes contribute the most lookups.

When you approach the limit, the tool recommends practical restructuring options—such as removing stale providers, splitting senders across subdomains, or adopting a managed include—so authentication remains stable as your stack grows.