CxO Tools / Deliverability / Email Errors / SPF

SPF PermError: Too Many DNS Lookups (over the limit of 10)

SPF (Sender Policy Framework, RFC 7208) caps how much DNS work a receiver must do to evaluate your policy: the whole recursive evaluation of one SPF record must not require more than 10 mechanisms/modifiers that cause a DNS query. The counted terms are include, a, mx, ptr, exists, and the redirect modifier: the initial TXT lookup of the domain itself does not count, and ip4/ip6/all cost nothing. The limit applies across the entire expansion tree: every include: is followed recursively and its own lookups add to the same running total. When evaluation would exceed 10, the receiver must stop and return PermError (a permanent error), not SoftFail or Neutral. Related sub-limits: mx and ptr may each trigger at most 10 additional queries, and void lookups (NXDOMAIN / empty answers) are capped at 2.

Why it matters

A PermError means your SPF policy is broken as published, so receivers cannot cleanly authenticate your mail via SPF. Many mailbox providers treat PermError as an SPF failure, removing an authentication pass. That degrades deliverability: mail is likelier to land in spam, and under DMARC, SPF no longer contributes a passing, aligned result, so if DKIM also fails or isn't aligned, DMARC fails and your p=quarantine/reject policy can junk or bounce legitimate mail. It is silent: the record looks valid, so senders often only discover it via DMARC aggregate reports or a checker after deliverability has already dropped. This is governed by RFC 7208 (Sender Policy Framework).

Common causes

  • Stacking many SaaS senders, each added as its own include: (Google, Microsoft 365, Salesforce, Mailchimp, SendGrid, Zendesk, HubSpot, etc.), the includes add up fast.
  • A single provider include costing multiple lookups internally: include:_spf.google.com expands to ~4 lookups, and include:spf.protection.outlook.com and others similarly nest further includes.
  • Nested/chained includes where one vendor's SPF include:es a partner, which include:es another, the recursive tree blows past 10 even with only a few top-level entries.
  • Using a, mx, or ptr mechanisms that each cost a lookup (and mx/ptr can each fan out to many more) when a plain ip4:/ip6: would cost zero.
  • Leftover includes for senders you no longer use, or duplicate includes for the same provider added by different admins over time.
  • redirect= modifiers pointing at a shared corporate SPF that itself already has many includes.

How to fix SPF PermError

  1. Run your domain through an SPF checker (e.g. an MXToolbox-style tool or a mail-health report) that expands the full tree and reports the exact DNS-lookup count and which mechanisms consume them, fix from data, not guesswork.
  2. Audit every include:, a, mx, ptr, exists, and redirect and map each to a sender that actually sends mail for this domain today. Delete includes for retired or never-used services: this is usually the biggest, safest win.
  3. Remove costly mechanisms you don't need: drop ptr entirely (deprecated and expensive), and replace a/mx with explicit ip4:/ip6: ranges when the sending IPs are stable, since literal IPs cost zero lookups.
  4. Consolidate providers where possible and prefer each vendor's most compact include; some vendors publish a leaner SPF include or let you host their IPs directly.
  5. Move dedicated bulk/marketing streams onto subdomains (e.g. news.example.com, mg.example.com) with their own separate SPF records, so each record has its own independent 10-lookup budget instead of competing in one.
  6. Only if you still exceed 10, consider SPF flattening: replace includes with the resolved ip4:/ip6: ranges. Understand the trade-off: flattened records are static and go stale when a provider changes IPs (silently breaking auth), so use a maintained/monitored flattening service or automation and re-verify regularly; also watch the 255-character-per-string / 512-byte practical record-size limits.
  7. Re-check the record after changes to confirm you are at 10 or fewer lookups, then monitor DMARC aggregate (RUA) reports to confirm SPF is passing and aligned for your real senders.
SPF Record Generator

Frequently asked questions

Does the initial lookup of my domain's SPF record count toward the 10?

No. The first TXT lookup that retrieves your published SPF record is not counted. The limit of 10 applies only to the DNS-querying mechanisms encountered during evaluation - include, a, mx, ptr, exists - plus the redirect modifier. ip4, ip6, and all cost nothing.

Can I just split my long record into two SPF TXT records on the same domain?

No, that makes things worse. RFC 7208 requires exactly one SPF (v=spf1) record per domain; publishing two results in a PermError regardless of lookup count. Combine everything into a single record and reduce lookups instead, or move some senders to subdomains that each get their own record.

Is SPF flattening safe as a permanent fix?

It works to get under the limit but shifts the risk. Flattening pins a provider's current IPs into your record; when that provider rotates or adds IPs, your record silently becomes wrong and their mail can start failing SPF. Only flatten with a service or script that re-resolves and updates the record automatically, and keep monitoring.

Will a PermError block my email outright?

Not by itself, SPF PermError doesn't hard-bounce mail on its own. But many receivers treat it as no/failed SPF authentication, which hurts spam placement and can cause DMARC to fail if DKIM isn't also passing and aligned. Under a DMARC reject policy, that can lead to legitimate mail being quarantined or rejected.

Related

Mail Health Report SuperCheck SPF Softfail (~all) Multiple SPF Records No DMARC Record DMARC p=none