SPF “too many DNS lookups”: the 10-lookup limit and real fixes
SPF stops counting at ten. Past that, receivers return a permanent error and your SPF fails for everyone, including mail that would have passed.
On this page
SPF lets a receiver run at most 10 DNS-querying terms (include, a, mx, ptr, exists and redirect) while checking a message, counting nested includes too. Over 10 is a permerror. Fix it by removing services you no longer use, moving third-party senders to their own subdomain, dropping a and mx when they aren’t senders, and replacing an include with ip4/ip6 ranges only for vendors with stable published IPs.
The rule
RFC 7208, the SPF standard, says: the include, a, mx, ptr and exists mechanisms and the redirect modifier cause DNS queries, and implementations “MUST limit the total number of those terms to 10 during SPF evaluation”. If the limit is exceeded, the result “MUST” be permerror.[1]
Two related limits catch people out:[1]
- Void lookups: implementations “SHOULD limit ‘void lookups’ to two”, meaning lookups that return no answer or NXDOMAIN. An include pointing at a name that no longer exists counts.
- MX: evaluating each
mxmechanism must not query more than 10 address records.
ip4:, ip6: and all cost nothing.[2]
Why “I only have 5 includes” still fails
Every include is a door into another SPF record, and that record’s own includes count too. Microsoft’s example: an include that points to a record with three more includes costs four lookups in total.[2] Large providers’ records often contain several nested includes each, so a handful of services can pass 10.
Google’s own help page phrases the limit as “up to 10 include: tags”;[3] the standard is stricter, because it counts nested lookups and the other mechanisms as well.
How to see your count
Expand your record the way a receiver would: count each lookup term in your record, then open each included record and count its terms, recursively. Or let a tool draw the tree.
Count your lookups
The domain report expands your SPF tree and shows what each include costs.
Fixes that last
| Fix | When it works | Watch out for |
|---|---|---|
| Remove senders you no longer use | Old newsletter tools, a previous host, a trial you cancelled | Check DMARC reports first to be sure nothing still sends |
Drop a, mx or ptr | When your website and inbound mail servers don’t send mail | ptr “SHOULD NOT be published” anyway[1] |
| Move a service to a subdomain | Marketing or ticketing mail can come from news.example.com | Each subdomain has its own SPF and its own budget of 10[2] |
| Replace an include with ip4/ip6 | Vendors with stable, documented IP ranges | You must track their changes; Microsoft says not to flatten its own include[2] |
| Rely on DKIM for a service | Services that sign with your domain | DMARC can pass on DKIM alone, so that service needs no SPF include |
Microsoft calls replacing includes with resolved addresses “SPF flattening” and lists when not to do it: for Microsoft 365, whose sending addresses change frequently, and for any cloud service with dynamic addresses. If you flatten, document what you replaced and review it at least quarterly.[2]
One more trap: two records
A domain “MUST NOT have multiple records” that a check would select;[1] two v=spf1 records are a permerror before counting even starts. Merge them into one.
Sources
- RFC 7208: Sender Policy Framework (SPF) (Apr 2014) · IETF / RFC EditorChecked 5 Oct 2026
- Set up SPF to identify valid email sources for your Microsoft 365 domain · Microsoft LearnChecked 5 Oct 2026
- Set up SPF · Google Workspace Admin HelpChecked 5 Oct 2026