SPF PermError: too many DNS lookups

SPF allows ten DNS-querying mechanisms per record, counted across every nested include, and your record goes past that. A record over the limit returns permerror, which receivers treat as no SPF at all, and nothing in your DNS panel shows it. Get the count to ten or below, and the next lookup after the TTL expires passes.

Where you will see it

Or, in a bounce from a stricter receiver, alongside 550 5.7.23. Or nowhere at all, which is the dangerous case: mail keeps flowing, DMARC loses its SPF leg, and the first hard evidence is a 550 5.7.515 weeks later when someone tightens a policy.

What counts

Mechanism	Costs a lookup	Note
include:	Yes, 1 each	Plus everything inside it
a	Yes, 1	Also a/24 style forms
mx	Yes, 1	Plus a query per MX host, capped at 10
ptr	Yes, 1	Deprecated by RFC 7208. Delete it.
exists:	Yes, 1	Rare outside macro setups
redirect=	Yes, 1	Plus the target record's own count
ip4: ip6:	No	Free. Use them.
all	No	Free

There is a second budget people forget: at most two "void" lookups, meaning queries that return no records. An include pointing at a name that no longer exists burns one of those and eventually errors the record on its own.

See your real number

Counting by hand means resolving every include recursively, and the includes have includes. Run the domain through the SPF checker instead: it walks the whole chain, prints the resolution tree, and shows the total against the limit of ten. Providers restructure their own records without notice: Google's include nested three records for years and was flat when I checked on 2026-08-20, so the number moves under you.

To see it yourself for one include:

Getting under the limit

1. Delete what you no longer use. Every SPF record over the limit that I have looked at had at least one include for a product the company stopped paying for. Start here; it is free.
2. Replace your own infrastructure with ip4:. If you know the addresses and control them, literals cost nothing and never surprise you. This does not apply to a platform whose IPs change without telling you.
3. Split by subdomain. The structural fix. Send marketing from news.example.com and give that subdomain its own SPF record with its own budget of ten. Relaxed DMARC alignment means it still aligns with your From domain, as long as the From address is on the subdomain too.
4. Drop ptr and any a or mx you do not need. An mx mechanism authorizes your inbound servers to send, which is usually not a thing they do.
5. Flatten last, and only the stable parts. Turning an include into IP literals works until the provider renumbers. If you flatten, write down what you flattened and check it on a schedule you will keep. Or let something re-resolve it for you on a schedule: our hosted SPF serves your record behind one include you publish, with every sender's addresses refreshed hourly.

The thing to fix first

Get DKIM signing correctly for every sender before you spend a weekend on SPF arithmetic. DKIM has no lookup budget, it survives forwarding, and a domain with aligned DKIM everywhere passes DMARC even on a day when SPF is in permerror. SPF still needs fixing. It is just not the emergency it feels like. The long version of this argument, with the arithmetic, is in the guide.

You fixed this sender. Tomorrow the reports list the other hosts still sending as you, and we read a day of XML and send you one email that says, sender by sender, what passed. On the paid plans, the day a new sender first shows up failing, you hear about it. Get the weekly digest. The first domain is free.