Cause · impact · fix
SPF PermError: too many DNS lookups
Your SPF record needs more than 10 DNS lookups to evaluate, so receivers stop and mark it broken. Here is why, what it costs you, and how to get back under the limit.
What it means
The cause.
SPF is evaluated by counting the mechanisms in your record that require a DNS query — every include:, a, mx, ptr, exists and redirect. The specification caps that count at 10. Go over it and the receiver stops evaluating and returns a permanent error: PermError.
The count is cumulative and nested, not one per line. An include: pulls in another provider's record, which has includes of its own, and all of them count against your ten. Google Workspace alone spends three or four. Add a CRM, a helpdesk and a newsletter tool and you are over the limit without ever writing a long record.
PermError is not a temporary hiccup or a soft warning. It means your SPF is structurally invalid, and it stays that way on every message until you reduce the number of lookups.
Why it matters
The impact.
A PermError record neither passes nor fails cleanly — most receivers treat it exactly as if you had published no SPF at all. One of the two ways to authenticate your mail is simply gone.
That matters most through DMARC. DMARC passes only when SPF or DKIM both passes and aligns with your From: domain. A broken SPF removes one of those two legs, so any message that was leaning on SPF to satisfy DMARC now fails it — and since 2024 Gmail, Yahoo and Microsoft require DMARC to pass for bulk senders. The visible symptom is mail that used to land quietly starting to hit spam or bounce.
What to do
The fix, in order.
Work top to bottom, then re-check — DNS changes take a few minutes to take effect.
- 1 See your exact lookup count. Run your domain through the SPF checker. It counts every mechanism, shows which include: is the most expensive, and tells you precisely how far over ten you are — so you fix the right thing, not a guess.
- 2 Remove what you no longer send through. Every include: for a service you have stopped using still costs a lookup. Drop the CRM you migrated off, the trial tool you never removed, the vendor from two years ago. This alone often gets you back under the limit.
- 3 Consolidate your senders. If several tools relay through the same provider, route them behind one include: instead of several. Fewer sending services means fewer lookups.
- 4 Flatten the most expensive includes, carefully. Replace a heavy include: with the ip4: and ip6: ranges it currently resolves to. It drops the count, but those ranges change: flatten only what you control, or what a service keeps in sync for you, and re-check periodically.
- 5 Re-check until you are under ten. DNS takes a few minutes to propagate. Run the checker again to confirm the count is 10 or below and the PermError is gone before you rely on it.
Confirm the error is gone.
Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.
Common questions