An SPF PermError from too many DNS lookups means the published record could not be evaluated. RFC 7208 section 4.6.4 still caps DNS-querying mechanisms and modifiers at 10. Receivers must return permerror once that cap is crossed, so the message is not an SPF pass. The fix is to remove or relocate mechanisms, not to add another include.
What an SPF permanent error actually blocks
Permerror is a permanent interpretation failure. RFC 7208 section 2.6.7 says the domain's published records could not be correctly interpreted and that a DNS operator has to fix them. It is not temperror, which is a temporary DNS failure, and it is not a blocklist hit.
If a mailbox provider requires SPF before it will treat the message as authenticated, a PermError leaves SPF neither pass nor fail. DMARC can still pass on DKIM alignment, but you should not rely on that as the cleanup. The alignment article covers why an SPF pass and a DMARC pass are different results.
Which terms count toward the 10-lookup cap
The limit is on terms that cause DNS lookups during evaluation, tracked as one global budget across nested includes and redirects. These count:
- include — each include is a lookup, and the included record's own DNS terms count too.
- a — address lookup for the named domain.
- mx — the mx mechanism counts once toward the 10. The follow-up address lookups for each MX hostname do not count toward the 10, but RFC 7208 caps them at 10 per mx mechanism, and crossing that is itself a permerror.
- ptr — avoid it. It is expensive and unreliable.
- exists — one lookup per evaluation.
- redirect — the redirect target is part of the same 10-lookup budget.
These do not count toward the 10: all, ip4, ip6, and the exp modifier. Replacing a vendor include with a stale list of ip4 addresses is flattening. That can silence the error and then fail later when the vendor changes addresses. Treat it as a last resort, not step one.
A separate void-lookup rule exists. RFC 7208 says implementations should limit lookups that return no records or NXDOMAIN to two, and exceeding that also produces permerror. That is not the same failure as crossing 10. If a checker says "too many DNS lookups," confirm it is the 10-term cap before you chase missing hostnames.
Why the cap exists, and how a single vendor include hides nested lookups, is covered in SPF 10 DNS lookup limit. This page owns the cleanup order.
How we checked the rule before writing the fix order
On 7 October 2026 we re-read RFC 7208 sections 2.6.7 and 4.6.4. The 10-term cap is still a MUST, and no later standards-track change has raised it. We also re-read Arawa Mail's enable sending guide. Activating sending adds DKIM CNAMEs and a custom MAIL FROM domain, with that hostname's own MX and SPF written through Cloudflare, and only after receiving is active. The docs do not publish an Arawa include string or a lookup counter, so the product will not show you a lookup total.
Public checkers (dmarcian, MXToolbox, Google Admin Toolbox) report the same PermError class. If two tools disagree, expand the live TXT against authoritative DNS yourself. A checker count is a hint, not the record.
Fix order: remove, then split, then flatten
Work on the apex TXT that receivers actually query. There should be one SPF record. Two TXT records that both start with v=spf1 are already a permerror, before the lookup count matters.
- Read the live TXT. Query the apex for TXT and copy the single v=spf1 record. Do not edit from a screenshot of an old host panel.
- Expand every include. Resolve each include and redirect, then count include, a, mx, ptr, exists, and redirect terms, including nested ones. Note which vendor added the terms that crossed 10.
- Delete unused vendors first. The usual culprit after a migration is a leftover host, ticketing, or marketing include. Removing that one term is the first test. A record that stacks Google, a marketing tool, a helpdesk, and an old host often falls back under 10 once the old host is gone.
- Do not add another include to "fix" the error. Another vendor include spends more of the same budget.
- Move one stream to a subdomain. Transactional mail on a subdomain has its own SPF budget and does not inherit the apex lookup count. See SPF on subdomains. That is the right split when two current vendors both need to stay.
- Only then consider flattening. Flattening replaces includes with ip4 or ip6 so those terms stop counting. It also freezes vendor addresses until you refresh them. Do that only after unused terms are gone and a subdomain split is not enough.
If two vendors must share one visible From domain, authentication has to be designed, not stacked. Two vendors, one From address is the companion piece. Free authentication checks is the way to retest SPF, DKIM, and DMARC after the DNS change, without treating a checker as authoritative.
What to do with an Arawa Mail MAIL FROM domain
Arawa Mail's custom MAIL FROM hostname carries its own MX and SPF. That SPF authorizes the return path. It is not something you paste into the visible From domain unless you have a specific alignment reason. Adding those mechanisms to the apex can spend lookup budget you just freed. Alignment between the visible From and the MAIL FROM domain is a separate decision from the 10-lookup cleanup.
Sending still requires receiving to be active first, and the DNS writes go through Cloudflare. If the domain is not on Cloudflare, activation stops at the authorization step. None of that changes the RFC cap on the apex.
FAQ
What does SPF PermError too many DNS lookups mean?
The evaluator hit more than 10 DNS-querying mechanisms or modifiers while reading the SPF record, including nested includes. RFC 7208 requires a permerror result. The message is not an SPF pass until a DNS operator reduces that count.
Which mechanisms count, and which do not?
include, a, mx, ptr, exists, and redirect count. Nested includes count. all, ip4, ip6, and exp do not. An mx mechanism counts once toward the 10, but its MX hostnames' address lookups have their own separate cap of 10.
How do I find the include that crossed 10?
Expand the live apex TXT and count DNS terms inside each include. The term that takes the running total from 10 to 11 is the one that triggers PermError. A leftover host include is the first candidate to remove.
Should I flatten, remove a vendor, or split a subdomain?
Remove unused vendors first. If two live senders still overflow the apex, put one stream on a subdomain. Flatten only after those options are exhausted, because flattened addresses go stale.
Does Arawa Mail show the SPF lookup count?
No. The sending guide adds DKIM CNAMEs and a custom MAIL FROM domain with its own MX and SPF. It does not publish an include string or a lookup debugger. Check the live TXT yourself.