Skip to content
critical

SPF PermError: too many DNS lookups (the 10-lookup limit) — how to fix it

Every include:, a, mx, ptr, exists and redirect= term in your SPF record costs one DNS lookup, and the terms inside the records you include count too. RFC 7208 §4.6.4 caps the total at 10.

Cross that line and receivers return PermError. The failure is invisible: no bounce, no warning, and mail that used to authenticate simply stops doing so. This is the single most common way a working SPF setup breaks, because it happens one vendor at a time — every new SaaS sender adds another include, and one of them eventually pushes you to 11.

The counter is cumulative and recursive: include:_spf.google.com alone costs 4 lookups, not 1, because of the records nested inside it.

How to fix it

  1. 1Get an exact count. Anything above 10 is already failing, and 8 or 9 means the next vendor breaks you.
  2. 2Remove includes for services you no longer use. This alone usually solves it — most over-limit records contain at least one dead vendor.
  3. 3Replace an include: with the vendor's specific ip4: / ip6: ranges where they publish stable ones. IP mechanisms cost zero lookups.
  4. 4Drop the mx and a mechanisms if your mail servers are already covered by an include: — they are frequently redundant and cost a lookup each.
  5. 5Never use ptr. It is deprecated by RFC 7208 §5.5, costs a lookup, and receivers may ignore it.
  6. 6If you still cannot fit, consider an SPF flattening service — but understand it makes a third party load-bearing for your mail flow, and flattened IP lists go stale.

Check whether your domain has this problem

Free, no signup, about two seconds. You get the exact record to paste.

Related guides