SPF stops evaluating after ten DNS lookups and returns permerror
What happens when an SPF record goes over the 10 lookup limit?
In one sentence
Every include: is a lookup, and you get ten.
Plain English
Every include: is a lookup, and you get ten. Past that your does not fail politely, it fails to run at all, and everything it would have authorised is now unauthorised. It breaks the day somebody adds the eleventh tool, and nothing announces it.
Why it matters. Every include: is a lookup, and you get ten.
Dotted words open definitions. See how email actually works.
What to do
Your move — not a lecture
Part platform, part you
The platform covers the mechanical bit. The judgement is still yours.
Your platform publishes its own include and keeps it working. Several vendors also publish a flattened or macro-based include that resolves in fewer lookups, and some -hosting services exist precisely to keep you under the ceiling.
Your part: Counting your own record, and deciding which tools come out. Nobody else knows which of the includes on your domain belong to a platform you stopped paying for.
What to do first
Count the counting terms in your own record — include, a, mx, , exists, redirect — and remember that each include drags in whatever that vendor nested inside it, so ten written terms can be fifteen real lookups. Anything you no longer send from comes out today. If you are still over after that, ask each remaining vendor whether it publishes a flattened include; several do and none volunteer it.
You can skip this if: Your record contains three or four includes and has not changed in a year.
Who this applies to
Any domain whose record contains more than ten of the counting mechanisms — which in practice means anyone who has added a new tool without removing an old one.
Checklist
- 01Count include, a, mx, , exists and redirect. Do not count all, ip4, ip6 or exp.
- 02Remove includes for platforms you no longer send from, which is almost always the cheapest fix.
- 03Do not flatten a vendor's include into raw ip4 addresses unless you own a process to re-flatten it — their addresses change and yours will silently go stale.
- 04Read your for permerror before assuming the record is fine.
That’s enough to act. The exact wording, the enforcement record and every primary source sit under Proof & sources, for counsel, bosses, or AI tools that need a citation. Not legal advice.
Proof
Exact position, enforcement, sources
For records and people who will check you. Skip if Monday’s move is already clear.
The exact position
RFC 7208 requires an evaluator to stop after ten -querying terms and return permerror. The terms that count are include, a, mx, , exists and the redirect modifier; all, ip4, ip6 and exp do not count. A permerror is not a soft failure a receiver forgives: your record has failed to evaluate, so nothing in it authorises anything, and a domain at p=quarantine or p=reject that relied on loses it. Two separate limits sit alongside it: the mx mechanism may not query more than ten address records, and evaluators should cap void lookups at two.
What happens if you do not
No regulator is involved. The consequence is mechanical and immediate: receivers treat permerror as a failed evaluation, so -based stops working. Mail that also aligns on survives; mail that relied on SPF alone does not.
Sources
- RFC 7208 § 4.6.4, Processing LimitsPublished 1 Apr 2014Read primary source
- Google Workspace Admin Help, Email sender guidelinesNo publisher dateRead primary source
History of this page
- Added. The domain check has flagged records over the limit since it shipped and had no page to link to.
Related
Take this with you
GET https://emailrules.today/rules/spf-ten-lookup-limit-returns-permerror?format=json
Same URL, same answer, every field including the ones behind the Proof tab. An Accept: application/json header on the plain URL does the same thing. All the endpoints.