SPF Permerror: Too Many DNS Lookups

SPF allows a maximum of ten DNS lookups during policy evaluation. If your record exceeds that limit, receivers return a permerror instead of a normal pass, fail, or softfail result. This is one of the most common SPF problems on growing domains, because each new email provider often adds another include, redirect, mx, or a-based lookup path.

One-Minute Fix

Reduce the number of include, redirect, a, and mx mechanisms so the full SPF evaluation stays under the 10-DNS-lookup limit.

Example optimized SPF record
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net ~all

A shorter-looking record is not always enough on its own. What matters is the total effective lookup chain after nested includes are expanded.

Re-check

Wrong vs correct setup

Lookup-heavy SPF example

Lookup-heavy SPF example
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:amazonses.com mx a redirect=_spf.example.com ~all

This kind of SPF policy may exceed the lookup limit once nested includes and other mechanisms are fully evaluated.

Simplified SPF example

Simplified SPF example
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net ~all

A cleaned-up policy with fewer dependencies is easier for receivers to evaluate and less likely to trigger SPF permerror.

Why this happens

SPF lookup limits are easy to exceed because one visible include can hide several more lookups underneath it. Over time, domains often accumulate several providers, legacy services, and redirect chains until SPF breaks under its own complexity.

Why this is a problem

  • SPF evaluation fails with permerror instead of a usable result.
  • Legitimate mail can lose SPF authentication.
  • DMARC alignment may fail when SPF was the expected path.
  • Authentication becomes inconsistent between mailbox providers.

How this affects deliverability

When SPF returns permerror, mailbox providers see a broken authentication layer rather than a deliberate sender policy. That weakens trust and can contribute to spam placement or erratic filtering decisions.

Common causes

  • Too many email providers were added over time.
  • Nested vendor include chains expanded beyond the SPF lookup limit.
  • Legacy senders remained in SPF long after they stopped sending.
  • A redirect combined with mx, a, and include mechanisms created too much DNS work.

What we checked

We evaluated whether the SPF policy structure is likely to exceed the 10-DNS-lookup limit once includes, redirects, and other lookup-based mechanisms are fully expanded.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

Can a short SPF record still exceed 10 lookups?

Yes. A short-looking record can still fail if the include mechanisms underneath it expand into many nested lookups.

Does SPF permerror always mean the syntax is wrong?

No. The syntax may be valid, but the evaluation path can still exceed the DNS lookup limit.

How do I fix SPF permerror?

Remove obsolete services, simplify the record, and flatten only when necessary so the total lookup count stays under ten.

Next steps

  • List every active sender before making changes to SPF.
  • Remove providers that no longer send mail for your domain.
  • Avoid unnecessary mx and a mechanisms when simpler options exist.
  • Flatten specific includes only if cleanup alone is not enough.
  • Re-test the final SPF policy to confirm it stays under 10 lookups.
  • Review the full troubleshooting guidance in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues