SPF 10 DNS lookup limit explained: why it fails and how to fix permerror

spf

If SPF suddenly starts failing with permerror, the root cause is often not syntax. It is lookup budget.

SPF evaluation has a hard cap on DNS-querying terms, and once that cap is exceeded, receivers are expected to return a permanent error. This is defined in RFC 7208 section 4.6.4, and it is still the operational baseline in 2026.

The short version: SPF gives each evaluation only 10 lookup-causing terms. Complex sender setups with many include: chains can burn through that budget fast.

What actually counts toward the 10-lookup limit

Per RFC 7208, these SPF terms trigger DNS lookups during evaluation:

  • include
  • a
  • mx
  • ptr (not recommended in modern deployments)
  • exists
  • redirect (modifier)

And these do not consume lookup budget directly:

  • ip4
  • ip6
  • all

Two details that catch teams off guard:

  1. A single include: can expand into more lookup-causing terms downstream.
  2. The limit is tracked across the whole evaluation path, not just one SPF record string.

So this record can look harmless but still exceed limits in practice:

example.com. IN TXT "v=spf1 include:_spf.mailer.example.net include:_spf.crm.example.net include:_spf.marketing.example.org -all"

If those included records are nested and use more include/mx/a terms, the receiver can legitimately return permerror.

Why this matters for DMARC outcomes

DMARC uses SPF only when SPF produces a passing, aligned result for the 5321.MailFrom domain (or fallback behavior for null reverse-path cases), as described in RFC 7489 section 3.1.2 and section 4.1.

When SPF returns permerror, SPF cannot provide that aligned pass signal. If DKIM is also not aligned and passing, DMARC fails.

That is why lookup overrun is not just an SPF hygiene issue; it directly affects enforcement safety.

If alignment logic needs a quick refresh, keep DMARC identifier alignment deep dive open while auditing.

A practical way to audit lookup risk

Use this sequence instead of guessing:

  1. Collect every active sending domain and subdomain (example.com, marketing.example.com, alerts.example.net).
  2. Expand each SPF record recursively and count only lookup-causing terms.
  3. Flag records at 8+ as "high risk" even if not failing yet.
  4. Test with real headers (Authentication-Results) after each DNS change.

Example DNS checks:

dig TXT example.com +short
dig TXT marketing.example.com +short

Example header clues on a failed message:

  • spf=permerror in Authentication-Results
  • no aligned SPF pass for the From domain under DMARC evaluation

For hands-on header reading patterns, DMARC troubleshooting with real headers is a useful companion.

Mitigation patterns that hold up in production

There is no single universal fix, but these patterns consistently work.

1) Split mail streams by subdomain

If one root domain SPF record is carrying transactional, marketing, support, and platform traffic all at once, it usually grows past a safe lookup footprint.

Move streams to dedicated subdomains and publish lean SPF records per stream:

  • example.com for employee mail
  • marketing.example.com for campaign traffic
  • alerts.example.com for product notifications

That reduces cross-team coupling and keeps each SPF policy readable.

2) Remove stale includes aggressively

Many SPF records still reference old vendors months after migration.

If a sender no longer transmits mail, remove its include. This is often the fastest way to recover lookup budget.

3) Prefer stable ip4/ip6 where appropriate

For infrastructure under direct control and stable addressing, explicit ip4/ip6 can reduce dependency depth.

Use reserved example ranges in documentation and testing, for example:

example.com. IN TXT "v=spf1 ip4:192.0.2.10 ip4:198.51.100.0/24 -all"

Do not copy these values literally into production.

4) Be careful with full SPF flattening

Flattening can reduce lookups, but fully flattened records can become brittle when upstream sender IP pools change.

A safer approach is selective flattening for known-stable sources plus periodic validation.

5) Keep one SPF TXT record per name

Multiple SPF TXT records at the same host produce SPF permerror for a different reason (record selection ambiguity), which is also defined in RFC 7208 section 3.2.

Provider guidance still points the same direction

Major mailbox providers continue to require clean authentication posture:

  • Google sender guidance requires SPF/DKIM baseline and DMARC for bulk senders, with alignment expectations (Google email sender guidelines).
  • Yahoo sender requirements likewise emphasize SPF, DKIM, DMARC, and alignment for bulk sending (Yahoo sender requirements).
  • Microsoft documentation calls out SPF design details, including lookup-limit troubleshooting in Microsoft 365 environments (Microsoft SPF setup guidance).

Different words, same operational reality: SPF has to be valid, maintainable, and under lookup limits.

A simple rollout plan that avoids surprises

If SPF is already near the edge, avoid big-bang edits.

  1. Inventory active senders.
  2. Trim stale includes.
  3. Split high-volume streams to subdomains.
  4. Re-test with live mail flow and DMARC reporting.
  5. Repeat until each record has comfortable lookup headroom.

If broader sender hygiene is in flight, Email sender requirements update guide (Google/Yahoo/Microsoft) and What is SPF? pair well with this checklist.

Bottom line

The SPF 10-DNS-lookup limit is not a soft recommendation. It is a protocol guardrail.

Treat SPF as an actively maintained dependency graph, not a one-time TXT record. Teams that keep SPF small and segmented avoid permerror incidents and make DMARC enforcement far safer.

Previous Post