Receivers stop evaluating SPF after 10 DNS lookups and return permerror. With DMARC in place, any mail that relied on SPF to pass now fails, and nothing in your inbox tells you. The usual cause is one more tool added to an already long record.
What counts
| Term | Costs a lookup? |
|---|---|
include: | Yes, plus everything inside the included record |
a, mx, exists:, ptr | Yes, one each |
redirect= | Yes |
ip4:, ip6:, all | No |
The nesting is what catches people. include:_spf.google.com costs 1 today, but some marketing and CRM platforms publish includes that contain three or four more includes each. The number that matters is the whole tree. Our checker follows every branch and gives you the total.
There's a second, lesser-known limit: no more than 2 "void" lookups, meaning names that return nothing. And an include whose target has no SPF record at all is a permanent error by itself. An include for a service you cancelled years ago is the usual culprit.
Five ways to get under 10
- Remove what doesn't send any more. Old newsletter tools, a previous mail host, a website plugin you replaced. This alone fixes most records.
- Remove includes that do nothing for you. Many tools send with their own bounce domain, so your SPF record is never consulted for their mail. If a tool's setup page asks only for DKIM records (often CNAMEs) and no SPF include, its include isn't needed.
- Drop
aandmxif those servers don't send. Lots of records carrya mxout of habit. If your web server and inbound mail servers don't send outbound mail, both are wasted lookups. - Move a sender to a subdomain. Bulk mail from
news.yourcompany.comgets its own SPF record with its own 10 lookups. DMARC still passes under relaxed alignment because the organisational domain matches. - Flatten, carefully. Replace an include with the
ip4:andip6:ranges it resolves to today. That costs zero lookups, but if the provider changes its ranges your record is silently wrong. Only flatten providers with stable published ranges, or use a service that re-flattens automatically.
Worked example
Take this record:
v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:servers.mcsv.net include:sendgrid.net include:old-crm.example ~all
Say the business moved from Microsoft 365 to Google two years ago, dropped the old CRM, and its web server doesn't send mail. Removing a, mx, the Microsoft include and the CRM include saves at least 4 lookups. Whether what's left fits depends on how many lookups each remaining include holds today, which is why you count the tree and not the top line.
Questions people ask
Does Gmail really reject over 10 lookups?
The limit is in the SPF standard (RFC 7208), and receivers that follow it return permerror. SPF then can't help the message pass DMARC. Whether it's rejected depends on DKIM and your DMARC policy.
Is SPF flattening safe?
It works until the provider changes its IP ranges. Then mail from the new ranges fails SPF and nobody tells you. Try removing includes and using subdomains first.
Do ip4 entries count?
No. Only terms that need a DNS query count: include, a, mx, ptr, exists and redirect.
Related guides
- How to create an SPF record that actually passes One record, every service that sends as you, and the right ending.
- Two SPF records? Merge them into one Why two records fail every message, and how to merge them.
- How to read a DMARC aggregate report Tell your own services from spoofing, and fix each kind of failure.
DNS only shows part of the picture. If mail is still landing in spam with every record right, the deliverability audit looks at the rest: blocklists, reputation, bounces, content and the sending setup.