SPF PermError: too many DNS lookups

SPF has a limit of ten DNS-querying mechanisms per record, counted across every nested include, and your record goes past it. Receivers read the record left to right and stop at the first match. A sender they need an eleventh lookup to find gets permerror and fails SPF. Nothing in your DNS panel shows the error. Get the count to ten or below, and the next lookup after the TTL expires passes.

Does a permerror bounce your mail? Not by itself. Mail from a sender that receivers need an eleventh lookup to find can pass DMARC only on aligned DKIM.

Where permerror shows up

A stricter receiver puts it in a bounce, next to 550 5.7.23. It can also show up nowhere at all, and that's the dangerous case. Mail keeps arriving while the senders that need an eleventh lookup can no longer pass DMARC on SPF. The first hard evidence comes weeks later, as a 550 5.7.515 when someone tightens a policy.

Which mechanisms count toward ten

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

SPF also has a limit of two "void" lookups, meaning queries that return no records. An include pointing at a name that no longer exists uses up one of them, and past the limit the record returns permerror on its own.

Your real lookup total

Counting by hand means resolving every include recursively, and the includes have includes. Run the domain through the SPF checker instead. It follows the whole chain and shows each include and your 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 20 Aug 2026. Your total can change without any edit on your side.

To check one include yourself, query it with dig:

Fixes

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, since it's 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. 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. With an mx mechanism, you authorize your inbound servers to send, and they usually don't.
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 have it re-resolved for you on a schedule. With our hosted SPF, you publish our include and we serve your record behind it, refreshing every sender's addresses hourly.

DKIM and SPF permerror

Get DKIM signing correctly for every sender before you spend a weekend on SPF arithmetic. DKIM has no lookup limit and survives forwarding. A domain with aligned DKIM everywhere passes DMARC even while SPF is in permerror. SPF still needs fixing, but it can wait until DKIM is done. The SPF 10-lookup limit guide has the longer argument, with the arithmetic.

You fixed this sender. The DMARC reports list every other host that sends as you, and we read them and email you one summary each Monday that says, sender by sender, what passed. On a paid plan, we also email you the day a new sender first fails. Get the weekly digest. Your first domain is free.