Background
The SPF ten DNS lookup limit: what RFC 7208 actually requires
Sender Policy Framework (SPF) tells receivers which hosts may send mail for your domain. The standard also hard-caps how much DNS work a receiver must do while checking that policy. Cross the cap and legitimate mail can fail authentication even when every include looks correct.
This guide summarises RFC 7208 for operators. Always verify counts with a live SPF checker against your published TXT record.
Why a hard limit exists
Every SPF include, a, mx, ptr, exists or redirect can trigger more DNS queries, and includes nest recursively. Without a cap, a crafted or accidental policy could force receivers into unbounded DNS work. The IETF therefore requires a fixed budget: at most ten DNS-querying terms during one SPF evaluation. That budget protects resolvers and mail systems, not your marketing stack.
What counts toward the ten
Per RFC 7208 section 4.6.4, these terms count: include, a, mx, ptr, exists, and redirect. Nested includes count as well: each DNS-querying term inside an included record consumes the same shared budget. The initial lookup of your domain’s SPF TXT record itself does not count toward the ten.
What does not count
The mechanisms ip4, ip6 and all, and the exp modifier, do not consume the ten-term budget. That is why flattening replaces deep include trees with ip4 and ip6 literals (or a short hosted include that already resolves to addresses): evaluation stays cheap for receivers.
permerror is not a soft warning
If evaluation would need an eleventh DNS-querying term, compliant receivers MUST return permerror. That is a permanent SPF failure for the check, not a temporary DNS glitch. Under DMARC, failed or inconclusive SPF then depends on DKIM alignment and your published p= policy. Organisations often discover the problem only after a new SaaS include pushes them over the line.
Void lookups (the second, quieter limit)
RFC 7208 also discusses void lookups: DNS answers that are empty or NXDOMAIN while evaluating terms. Implementations SHOULD limit those to two (default recommended). Too many broken includes can therefore fail SPF even before you hit ten successful lookups. Keep dead includes out of production records.
mx and ptr have extra per-mechanism caps
Evaluating mx counts as one term toward the ten, but each MX host still has address-lookup limits described in the same section. ptr is similarly constrained and is generally discouraged in modern policies. Prefer explicit includes or address literals over ptr.
How operators usually burn the budget
A typical failure mode is stacking vendor includes: primary mailbox platform, marketing automation, ticketing, billing, and a catch-all for a legacy ESP. Each include may itself contain several includes. The portal TXT still looks short, but recursive evaluation exceeds ten terms. Another failure mode is publishing two SPF TXT records on the same name, which is also a permerror under the RFC.
How to measure before you change DNS
Use an SPF checker that expands includes recursively and reports term count and permerror. NovaMX publishes a free SPF check on the tools page. Run it against your live apex (or the exact name that carries v=spf1) before and after every sender change. Keep a change log of which product owns which include.
Remediation options (ordered)
- Remove unused includes and void targets.
- Prefer one mail platform’s documented include over many one-off ESP includes where possible.
- Use SPF flattening so receivers see a compact record while authorised IPs stay current.
- Never paper over failures with +all; that authorises the whole internet to send as you.
What NovaMX MailControl does
MailControl SPF Flattening stores your authorised senders, resolves includes on a schedule, and publishes a compact target for DNS. The portal shows lookup pressure before you publish. Flattening is available standalone or inside MailControl Essential and larger bundles. Rates are on the Pricing page. See also the SPF flattening how-to and What is SPF?
Relation to DMARC and BIMI
SPF alone does not set mailbox policy. DMARC decides what receivers should do when authentication fails, and BIMI typically expects a strong DMARC policy. A broken SPF budget undermines that whole path even if DKIM is perfect for some streams. Fix SPF count first, then ramp DMARC with reports.
Common questions
Is the limit ten DNS queries or ten SPF terms?
RFC 7208 limits DNS-querying terms (mechanisms and redirect). Some terms trigger more than one DNS query (for example mx). Operators and checkers should follow the RFC term budget, not a naive query counter.
Does flattening replace DMARC?
No. Flattening keeps SPF evaluable. DMARC still sets policy and reporting.
Can I stay under ten without flattening?
Sometimes, if you have few senders and short include chains. Many organisations cannot once marketing and SaaS stacks grow. Measure rather than guess.
Where do I start on NovaMX?
Run the free SPF tool, create a My NovaMX account, verify the domain, then order SPF Flattening or a MailControl bundle that includes it.
Next steps
Check your live record, read the flattening how-to if you need a hosted fix, then order MailControl when you are ready.