Bounce and error codes

SPF PermError: too many DNS lookups

Last updated 2026-08-21

SPF has a hard budget of ten DNS-querying mechanisms, counted across every nested include. Cross it and the record does not degrade gracefully. It stops working entirely, and nothing in your DNS panel will tell you.

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 authorises 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.

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 name the other hosts still sending as you, and we turn a day of XML into one email with a verdict per sender. On the paid plans, the day a report first names a new sender failing, you hear about it. Get the weekly digest. The first domain is free.