SPF "Too Many DNS Lookups": Why It Happens and How to Fix It

SPF has a hard limit of 10 DNS-querying mechanisms per evaluation. Go over it and receivers return a permerror, which most treat as an SPF failure — so your mail can miss DMARC alignment and land in spam even though your record “looks” fine. The limit is defined in RFC 7208 and it counts recursively, so nested include: chains are the usual culprit.

What counts toward the limit

RFC 7208 §4.6.4 caps the number of mechanisms and modifiers that cause DNS lookups at 10 per SPF check (RFC 7208). The terms that each cost one lookup:

• include:
• a
• mx
• ptr (deprecated — avoid it)
• exists:
• the redirect= modifier

Crucially, include: recurses: if you include a provider whose own record includes three more, those count too. A single include:_spf.google.com might be 1 — or, for other providers, many. ip4: and ip6: do not count, because they need no DNS lookup.

Why the limit exists

It’s an anti-amplification and performance measure: without a cap, one SPF check could fan out into dozens of DNS queries, which is slow for receivers and abusable for attacks. Ten is the ceiling every conformant receiver enforces.

How to get back under 10

1. Count first. Our free SPF checker counts your lookups recursively, including nested includes, and tells you the exact number — so you know how much you need to cut.
2. Remove providers you no longer use. Old include: entries for tools you’ve dropped are the easiest wins.
3. Replace include: with ip4:/ip6: where you can. If a sender publishes stable IPs, listing them directly costs zero lookups. (Trade-off: you must update them if the provider’s IPs change.)
4. Drop a, mx and ptr if unused. Many records carry an a/mx that isn’t actually sending mail. ptr is deprecated by RFC 7208 — remove it.
5. Flatten as a last resort. SPF-flattening services expand your includes into raw IPs and keep them updated. It works, but it hands your SPF record to a third party — use it only when you genuinely can’t get under the limit otherwise.

Don’t publish two SPF records

A domain must have exactly one v=spf1 record. Publishing a second one is invalid and fails SPF outright — a surprisingly common mistake when a new provider adds its own record instead of merging into yours. Our checker flags this too.

Keep it healthy

SPF drifts as you add and remove senders, so re-check after any mail change. SPF is only one of three — pair it with DKIM and a DMARC policy, or run the full report.

Sources

• RFC 7208 — Sender Policy Framework, §4.6.4 (the 10-lookup limit): https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4