Fix SPF Too Many DNS Lookups (PermError 10-Limit)

What's happening

Section 4.6.4 of RFC 7208 caps the number of DNS mechanisms that cause additional DNS lookups at 10 per SPF evaluation. Each include:, a, mx, exists, redirect, and ptr counts. The cap exists to prevent denial-of-service amplification through deeply nested SPF records.

When a receiver evaluates your record and walks past the tenth lookup, it stops and returns PermError. PermError is not a soft fail — it is treated as a hard authentication failure by every major provider. The bounce text in headers reads spf=permerror (PermError SPF Permanent Error: too many DNS lookups) and Microsoft 365 logs it as compauth=fail reason=000.

Most domains hit the limit by stacking marketing platforms that each ship with a long include chain. include:_spf.google.com costs 4, include:spf.mailgun.org costs 2, include:sendgrid.net costs 2, include:_spf.salesforce.com costs 5. Adding HubSpot or Klaviyo on top reliably pushes the total past 10.

Why it matters

PermError is harsher than a missing record. With no SPF record, receivers may still deliver based on DKIM and reputation. With PermError, your DMARC SPF check fails on every message and most receivers tag the mail spam=fail in headers regardless of DKIM. Gmail bulk-sender enforcement treats it as authentication failure.

Domain reputation in Google Postmaster Tools collapses within hours of high-volume sending under PermError. Microsoft 365 routes the mail through SmartScreen with a large negative bias, and Yahoo bounces with 554 5.7.9. Recovery takes weeks once reputation is damaged.

Worst of all, PermError is silent for many senders — you keep sending, mail still seems to arrive for some recipients, and only when DMARC aggregate reports come in (or Mail-Tester is run) does the problem surface.

Common causes

• Stacking 4+ ESP includes (Google + Mailgun + SendGrid + Salesforce) without flattening.
• Using include:_spf.salesforce.com which alone consumes 5 of 10 lookups.
• Nested includes inside vendor records pulling in third parties you do not see.
• Legacy ptr mechanism still in the record — RFC 7208 deprecates it and it counts toward the limit.
• redirect= chains that point to another SPF record with its own includes.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Audit current lookup count

   Run dig +short TXT example.com and paste the result into a checker that resolves nested includes (CheckFast Email Checker, MXToolbox SPF Survey, dmarcian SPF Surveyor). Note the exact total — anything 9 or higher is dangerously close.

2. 2

   Remove unused senders

   Cross-reference each include with the ESPs you actually use today. Domains routinely carry three-year-old Mandrill, Marketo, or Constant Contact includes. Anything with no traffic in the last 90 days should be removed first — that alone often drops the count by 4-6.

3. 3

   Replace heavy includes with ip4 or ip6

   For each remaining include, run dig +short TXT _spf.google.com (or whichever vendor) and resolve the chain to the underlying IP ranges. Replace include:_spf.google.com with the resolved ip4: and ip6: ranges. Each ip mechanism costs zero lookups. Document the source so you can refresh when the vendor rotates ranges (typically yearly).

4. 4

   Use a flattening service or automate it

   Tools like dmarcian SPF Macro, EasyDMARC SPF Flattening, or autospf.com publish a CNAME-pointable flattened record and refresh it daily. Cost is roughly $5-15/month and removes the maintenance burden of manual flattening.

5. 5

   Republish and verify under 10 lookups

   Publish the new record at TTL 300, run the lookup count check again, and confirm it shows 9 or lower (8 leaves headroom for a future vendor). Send a Mail-Tester probe and confirm the SPF row reads pass, not permerror.

6. 6

   Set up monitoring

   Enable DMARC aggregate reports (rua=) and review them weekly. The pct of messages with spf=permerror should be 0. If a vendor expands its include chain in the future, your reports will surface PermError before recipients complain.

Example

; Before — 12 lookups, fails PermError
example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.mailgun.org include:sendgrid.net include:_spf.salesforce.com include:servers.mcsv.net ~all"

; After — 6 lookups, flattened Google + Salesforce to ip4
example.com. IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:13.110.208.0/21 include:spf.mailgun.org include:sendgrid.net include:servers.mcsv.net ~all"

Replacing two heavy includes with their ip4 ranges drops the total lookup count below the 10-limit.

Related fixes