DEV Community

Cover image for SPF "too many DNS lookups" (PermError): what it means and how to fix it
North Dev
North Dev

Posted on

SPF "too many DNS lookups" (PermError): what it means and how to fix it

#email #dns #devops #security

Your mail quietly started landing in spam, and when you checked SPF you found this: PermError: too many DNS lookups. Here's exactly what that means and how to fix it without guessing.

The rule nobody tells you about

SPF (RFC 7208) caps the number of DNS-lookup-causing terms in your record at 10. Not 10 records — 10 lookups, counted recursively. Blow past it and a correct receiver returns PermError, which many treat as "SPF failed" — so your legitimate mail gets downgraded or junked.

What costs a lookup:

  • include: — 1 each, and you recurse into it (its own includes count too).
  • a, mx, ptr, exists — 1 each.
  • redirect= — 1 (when there's no all).
  • ip4: / ip6: / all — 0. These are free.

The trap is include:. One include:_spf.google.com can itself expand into several more includes. Add a few SaaS senders (include:mailgun.org, include:servers.mcsv.net, include:_spf.salesforce.com…) and you silently cross 10.

Diagnose it

Resolve your TXT record and walk the includes, adding up the lookup-causing terms across the whole tree. If the total is >10, that's your bug.

dig +short TXT example.com | grep spf1
Enter fullscreen mode Exit fullscreen mode

Then follow every include:/redirect= and count. (This is tedious by hand, which is the point — tooling should do it.)

Fix it

  1. Remove senders you no longer use. Old ESPs linger in SPF for years.
  2. Flatten a stable include into its ip4:/ip6: ranges (free lookups) — but only for senders whose IPs rarely change, and re-check periodically, or you'll authorize stale IPs.
  3. Delegate by subdomain. Send bulk/marketing from mail.example.com with its own SPF, keeping your root record lean.
  4. Prefer -all (hard fail) once you're confident; ~all (soft fail) while testing.

Don't stop at SPF

SPF alone doesn't survive forwarding. Pair it with DKIM (a signature that survives relays) and a DMARC policy that moves from p=none (monitoring) to p=quarantine/p=reject once your reports are clean. All three is what actually keeps you out of spam.

I bundled the SPF lookup-counter (and DKIM/DMARC/TLS checks) into a zero-config CLI, domain-doctor — domain-doctor example.com prints a graded report with the fix for each problem. MIT, single Go binary.

Top comments (0)