SPF Too Many DNS Lookups: How to Fix It

SPF

Introduction

RFC 7208 caps SPF resolution at 10 DNS lookups. Hit the limit and SPF returns permerror — which receivers interpret as fail. Your mail is suddenly failing authentication and you have no idea why.

This article covers identifying the cause, the three workable fixes, and how to keep the count under control going forward.

Why this topic matters

The 10-lookup limit is the most common SPF failure mode at scale. A growing company adds SaaS senders without realizing each include: directive costs 1-3 lookups. Crossing 10 doesn't show as an obvious error — your aggregate reports just start showing SPF failures across every sender. By the time you trace it, mail is bouncing.

How the lookup budget works

Every directive that requires a DNS lookup counts:

• include: — 1 lookup, plus the includes within (cascading)
• a: — 1 lookup
• mx: — 1 lookup, plus 1 per MX target
• ptr: — 1 lookup (deprecated; avoid)
• exists: — 1 lookup
• redirect= — 1 lookup

What doesn't count:

• ip4: and ip6: — resolved inline, no DNS lookup
• all — terminal mechanism, no lookup

A typical include:_spf.google.com adds 4-5 lookups by itself (Google's SPF includes other sub-SPFs). Stack a few SaaS senders and you're at 12 before noticing.

Step-by-step approach to diagnosing

1. Pull your SPF. dig +short TXT yourdomain.com | grep spf
2. Count manually or use a checker. Most free SPF validators report the lookup count.
3. Identify the heavy includes. Walk the chain — for each include:, look up that domain's SPF and count its lookups.
4. Choose a fix.

The three workable fixes

Fix 1: Move senders to DKIM-only

The cleanest fix. SaaS senders that support custom DKIM don't need SPF includes — DKIM provides the authentication without consuming the lookup budget.

Identify SaaS senders in your SPF that support DKIM (most do), enable DKIM for each, then remove their SPF include. Each removed include frees 1-5 lookups.

Fix 2: SPF flattening

Replace include: with the resolved IPs. Instead of include:_spf.google.com, list Google's current sending IPs directly with ip4: mechanisms. This bypasses the lookup but requires ongoing maintenance — IPs change.

Doing this by hand is fragile. Most DMARC platforms maintain a flattened record automatically, updating when IPs change. SPF flattening for MSPs covers the workflow.

Fix 3: Subdomain isolation

Move some senders to a subdomain with its own SPF record. Each subdomain has its own 10-lookup budget. marketing.yourdomain.com for the marketing SaaS, transactional.yourdomain.com for billing.

This requires the senders to use the subdomain in their envelope-from — usually a configuration option in the platform.

Best practices

• Audit when adding senders. Each new include is a budget decision.
• Prefer DKIM-only senders. Cleanest and most maintainable.
• Document the SPF. Future-you needs to know why each mechanism is there.
• Set a monthly check. A platform-driven alert when lookups exceed 8 catches drift early.
• Avoid deprecated mechanisms. ptr and +all aren't worth the trouble.

Recommended next step

Run your SPF through a free checker right now. If you're at 8+ lookups, plan the cleanup before you hit 11. The fix is rarely emergency-grade but always rolls up faster than expected.

For MSPs, this is a recurring client deliverable — SPF flattening for MSPs covers the productized version.

FAQ

What happens when SPF exceeds 10 lookups?

Receivers return permerror, which DMARC treats as fail. Mail will increasingly land in spam or get rejected at the policy level.

Can I just delete ~all to avoid the failure?

No. ~all is the terminal mechanism; without it the SPF semantics break in other ways. The actual fix is reducing lookups.

How do I know which include is consuming the most lookups?

A good SPF analyzer (like DMARC AI's free tool) walks the chain and reports lookups per include. The biggest consumers are usually large SaaS senders with chained SPF.

Does the lookup limit apply per check or per domain?

Per single SPF check — meaning every time SPF is evaluated for a piece of mail, the same 10-lookup limit applies. Caching helps performance but doesn't change the limit.

What about SPF macros?

Macros (the %{...} syntax) are advanced and rarely used. They don't help with the lookup count.

Final thoughts

The 10-lookup limit is artificial but real, and it has caused more silent DMARC failures than any other single misconfiguration. The fix is one of three patterns — DKIM migration, flattening, or subdomain isolation — and the best long-term answer is usually the first.

Treat the lookup budget as a finite resource. Each new SaaS sender that wants in costs something. Choose deliberately and the record stays healthy for years.