Fixing SPF PermError: Too Many DNS Lookups (The 10-Lookup Limit Explained)

The Sender Policy Framework (SPF), specified in RFC 7208, provides an email authentication mechanism allowing domain owners to designate authorized sending IP addresses in DNS TXT records. However, one of the most common and disruptive email delivery failures in enterprise email administration is the PermError: too many DNS lookups authentication result. When this error occurs, receiving mail servers abort SPF evaluation, which frequently causes legitimate outgoing messages to be rejected, quarantined, or sent to recipient spam folders under DMARC policy.

Why the 10-Lookup Limit Exists (RFC 7208 Section 4.6.4)

The 10-lookup limit is not an arbitrary constraint; it is a critical defensive specification introduced in RFC 7208 Section 4.6.4. In the early days of SPF deployment, security researchers identified that an adversary could create a malicious domain with circular or deeply nested SPF records containing dozens of include and redirect statements. If a spammer sent millions of spoofed emails to mail servers worldwide, every receiving mail server would initiate hundreds of recursive DNS queries to resolve the attacker's nested records.

This effectively transformed receiving mail transfer agents into unwilling participants in massive Distributed Denial of Service (DDoS) reflection and amplification attacks against third-party DNS authoritative nameservers. To prevent this vulnerability, the IETF strictly capped the maximum number of mechanisms triggering recursive DNS lookups to 10 per SPF evaluation.

The DNS Query Budget: Which Mechanisms Count?

Not all terms in an SPF record increment the DNS lookup counter. Understanding which mechanisms consume your 10-lookup allowance is crucial for optimizing your record:

The Hidden Danger: The 2-Void-Lookup Limit (RFC 7208 Section 11.1)

Many administrators are unaware that RFC 7208 also imposes a secondary limit: the void lookup limit. Section 11.1 specifies that if an SPF evaluation triggers more than 2 void lookups—meaning a DNS query that returns NXDOMAIN (Non-Existent Domain) or NODATA (RCODE 0 with an empty answer section)—the evaluation MUST terminate immediately with a PermError.

Nested Includes: How 3 Services Can Consume 11 Lookups

A common misconception is that an SPF record with only four include: statements cannot exceed 10 lookups. However, the 10-lookup limit is cumulative across the entire recursive tree. Every include: statement pulls in an external record that may itself contain nested include:, a:, or mx: mechanisms.

Your Domain TXT: "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:zendesk.com ~all"

Step 1: _spf.google.com (Lookup 1)
  -> includes _netblocks.google.com (Lookup 2)
  -> includes _netblocks2.google.com (Lookup 3)
  -> includes _netblocks3.google.com (Lookup 4)
Step 2: sendgrid.net (Lookup 5)
Step 3: mailgun.org (Lookup 6)
  -> includes mailgun.net (Lookup 7)
Step 4: zendesk.com (Lookup 8)
  -> includes mail.zendesk.com (Lookup 9)
  -> includes zendesk1.net (Lookup 10)
  -> includes zendesk2.net (Lookup 11) -> EXCEEDED: PermError triggered!

Four Architectural Strategies to Fix the 10-Lookup Limit

1. 1

   1. Audit and Prune Decommissioned Services

   Inspect every include in your TXT record. If your company switched CRM, transactional email, or customer support tools, immediately remove legacy SaaS includes (e.g., Mailchimp, SurveyMonkey, Pardot).

2. 2

   2. Eliminate Redundant 'a' and 'mx' Mechanisms

   Many organizations include 'a mx' by default. If your corporate web server does not send outbound email directly, remove 'a'. If your inbound MX servers are hosted by Google Workspace or Microsoft 365, 'mx' only authorizes your inbound mailboxes to send mail, which is redundant if Google/M365 includes are already present. Removing 'a mx' frees up 2 precious lookups.

3. 3

   3. Segment Senders Across Dedicated Subdomains (Enterprise Standard)

   Do not send all corporate email from your apex domain (@yourcompany.com). Reserve the root domain strictly for employee 1-to-1 correspondence (e.g., Google Workspace or Microsoft 365). Route marketing campaigns through 'marketing.yourcompany.com' and transactional alerts through 'billing.yourcompany.com'. Each subdomain publishes its own independent SPF record and receives a fresh, isolated 10-lookup budget.

4. 4

   4. Dynamic SPF Flattening vs Automated Macro Solutions

   SPF flattening replaces vendor include statements with direct 'ip4:' and 'ip6:' CIDR blocks. However, manual flattening is dangerous because cloud vendors dynamically rotate IP ranges without notice. Use automated dynamic flattening services with API monitoring, or deploy SPF macros (e.g., 'exists:%{i}._spf.example.com') to query sender IPs dynamically.

The Fatal Mistake: Never Publish Multiple SPF Records

When facing lookup limitations, some administrators attempt to bypass the limit by creating two separate TXT records on the root domain, placing half the includes in one and half in the other. This is a catastrophic error. RFC 7208 Section 3.2 explicitly dictates that a domain MUST NOT publish multiple SPF records. If a receiving mail server queries DNS and finds more than one record starting with v=spf1, evaluation MUST immediately fail with PermError.

Check your result and continue troubleshooting

Use the spf checker tool to inspect the public DNS data relevant to this guide. Record the hostname, query type, resolver and time so you can compare results after a change. This is a DNS check, not a guarantee of worldwide propagation or successful application delivery.

For the underlying behavior and current configuration guidance, consult the official reference. Provider dashboards can change; use the values shown for your own domain rather than copying an example into production.