My SPF Record Has Too Many DNS Lookups: How Do I Fix It?

Your SPF TXT looks like one line. Receivers expand it into a tree. When that tree needs an eleventh DNS lookup, the result is permerror and SPF fails for every message on the name, including mail that used to pass.

This is not a softfail you can ignore. It is a broken record until you shrink the tree or split the senders.

Why does my SPF record have too many DNS lookups?

SPF is evaluated at SMTP time. The receiver fetches your TXT record and follows each mechanism that requires DNS.

Common contributors:

• include: for every vendor (Google, Microsoft, ESP, CRM, support desk, billing, webinar tool).
• Nested includes inside vendor records (their include: pulls more include:).
• redirect= delegating to another domain’s entire policy (counts as a lookup and can chain).
• a and mx mechanisms on busy hostnames (lookup plus potential further resolution).

You did not add eleven tokens to your TXT. You added six, and the ESP’s own SPF added five more underneath.

Symptoms:

• Validators report “too many DNS lookups” or permerror.
• Headers show spf=permerror or Received-SPF: permerror on mail from IPs that are clearly yours.
• Everything fails at once after you added one new include:.

If only one vendor’s mail fails, you probably have a missing include, not lookup exhaustion. See why SPF fails for that shape.

What is the SPF ten lookup limit?

RFC 7208 limits DNS lookups to ten during SPF evaluation of a single record.

Mechanisms that consume lookups include include, a, mx, ptr, and redirect. The ip4: and ip6: mechanisms do not add lookups when used directly.

When the limit is exceeded, the spec requires permerror. Receivers treat the domain as having no valid SPF policy for that check. DMARC may still pass on DKIM alone, but SPF-aligned paths break and some receivers downgrade or reject.

There is no partial credit. Lookup eleven fails the whole evaluation.

How do I count DNS lookups in my SPF record?

Do not count commas in the TXT line. Expand the tree.

1. Paste your record into the SPF flattener or another validator that shows lookup count.
2. Note which include: branches cost the most (often ESP plus suite plus CRM on one domain).
3. Repeat for each subdomain that sends mail. Limits are per record, not per brand.

Example mental model:

v=spf1 include:google.com include:sendgrid.net include:crm.example ~all
         lookup 1         lookup 2            lookup 3 (+ nested inside each)

Nested depth is why two includes can cost six lookups.

What causes permerror besides duplicate records?

Duplicate SPF TXT records on the same name also cause permerror (two v=spf1 answers). Lookup limit permerror is different: dig +short TXT example.com returns one plausible line, validators still fail on count.

Confirm which you have before you edit. Merging duplicates and flattening are different fixes.

Should I remove SPF includes or flatten first?

Prune first. Flatten second. Split subdomains third.

Step	Action	Why
1	Remove include: for vendors that no longer send	Zero maintenance cost
2	Move bulk/marketing to mail.example.com with its own SPF	Splits lookup budget (subdomain split)
3	Flatten stable includes that still bust the limit	Buys headroom; needs refresh when IPs change
4	Avoid flattening huge providers unless you must	Google and Microsoft ranges change often

Removing an unused include: is always safer than freezing IPs that drift.

What is SPF flattening?

Flattening resolves include: targets to their published IP ranges and rewrites your record with ip4: / ip6: entries so receivers stop walking nested DNS.

Before (lookup-heavy):

v=spf1 include:_spf.google.com include:sendgrid.net include:intercom.io ~all

After flattening (conceptually):

v=spf1 ip4:209.85.128.0/17 ip4:... ip4:167.89.0.0/17 ... ~all

The TXT grows. The lookup count drops.

Trade-offs live in the SPF flattening guide: stale IPs fail legitimate mail silently until someone notices SPF fails again.

Is SPF flattening safe?

Conditionally yes.

Safe enough when:

• The flattened vendor publishes stable ranges and you re-run the flattener on a schedule.
• You flattened a small SaaS with infrequent IP changes.

Risky when:

• You flattened Google Workspace, Microsoft 365, or a major ESP that rotates infrastructure often.
• Nobody owns DNS maintenance after the flatten; the record rots.

If flattening is the only way under ten, automate re-checks or subscribe to provider status pages. One-time flatten and forget is how permerror turns into selective spf=fail.

How do I fix SPF permerror step by step?

1. Confirm permerror is lookup-related with the flattener or email health check.
2. Inventory senders from DMARC aggregate reports and last month’s mail headers. Mark active vs retired.
3. Delete dead includes from the TXT. Wait for TTL, retest count.
4. Split streams if marketing and transactional share one bloated record.
5. Flatten remaining includes until count is nine or lower (leave headroom for future adds).
6. Send tests from each platform; read Authentication-Results for spf=pass.
7. Document who may add the next include: so you do not cross ten again.

After the record is valid, consider -all only when DMARC reports show no surprise sources.

What to do next

Lookup-limit permerror is a infrastructure problem with a clear finish line: ten or fewer lookups, one SPF TXT per sending name, retested paths.

Once SPF is stable, align DKIM and DMARC so receivers have a second pass path. The Gmail and Yahoo requirements assume both SPF and DKIM for bulk senders.

Add the flattener to your recurring checks in the weekly deliverability review if your stack changes often. Lookup count is one of the few DNS metrics that goes wrong quietly until all mail fails at once.