Your SPF record can be perfectly valid, publish without a single error, and still fail every time it is checked. The reason is a rule most people never learn until it bites them: SPF is allowed at most ten DNS lookups per evaluation, and going over does not degrade gracefully. It fails outright.
In a scan I ran across the top 10,000 domains earlier this year, 1.7% were already over the limit. That sounds small until you realize these are among the most-managed domains on the web, and the number only goes up as a domain adds senders. It is the kind of problem you grow into without noticing.
What the limit actually is
RFC 7208, the SPF spec, caps the number of mechanisms that require a DNS lookup at ten per evaluation (section 4.6.4). The mechanisms that count are include, a, mx, ptr, and exists, plus the redirect modifier. The ones that do not count are ip4, ip6, and all, because they are answered from the record itself without another query.
Cross ten lookups and the evaluation returns permerror. That is not a soft "neutral" result you can ignore. A permerror means SPF produced no usable answer, so it cannot give you a pass. For DMARC that counts the same as a fail, and many receivers treat a standalone SPF permerror as a failure on its own.
Why it is silent
Nothing warns you. The record is syntactically fine, so it publishes cleanly and looks correct in your DNS panel. The count is only evaluated at the receiver, at send time, by expanding every include down its full chain. You do not see the failure; your recipients' mail servers do, and the only symptom is mail that quietly stops authenticating.
Why it creeps up on you
The culprit is almost always include: chains. An include does not cost one lookup, it costs however many the included record costs, recursively. include:_spf.google.com is around four lookups on its own, because it chains to several sub-records. Add Microsoft 365, a marketing platform, a helpdesk, an invoicing tool, and each one brings its own chain. Nobody adds "six lookups" on purpose; you add include:sendgrid.net, it looks like one line, and you are quietly over.
How to check
Count resolved lookups, not lines. Reading the record by eye undercounts badly because the expensive part is hidden inside the includes. Use a checker that expands every include and reports the real total against the limit of ten. That one number tells you whether you have a problem and how much headroom is left.
How to fix it
In rough order of how much they buy you:
- Remove what you no longer use. The fastest win is usually deleting includes for senders you stopped using a year ago. Audit the list against who actually sends your mail.
- Drop redundant mechanisms.
aandmxeach cost a lookup. If your MX hosts do not send outbound mail, you do not needmxin SPF at all. - Use the provider's consolidated include. Some providers replaced a sprawl of sub-records with one: Microsoft 365 is the classic example, where a single
include:spf.protection.outlook.comreplaces the old pile of entries. - Flatten stable senders. Replace an
include:with the actualip4:/ip6:ranges it resolves to. Those do not count toward the limit, so every include you flatten frees its lookups. The catch is maintenance: if that provider changes its IPs, your record is silently wrong until you update it, so only flatten senders whose ranges are stable. Your own infrastructure is a safe candidate; a big cloud provider's is not, keep those as includes. - Split senders onto subdomains. The limit is per record. If a source only ever sends as
mktg.example.com, give that subdomain its own SPF record and move its includes there, freeing lookups on your main domain.
The part people miss
SPF is not your only authentication leg, and it is the one with this limit. Aligned DKIM has no lookup cap and survives forwarding, where SPF breaks anyway. If you are fighting to squeeze a sender under the SPF limit, the better move is often to make sure that sender signs with aligned DKIM instead, and stop relying on SPF for it. DMARC only needs one of the two to pass and align, so a sender you cannot fit into SPF can still authenticate cleanly on DKIM.
The takeaway
The ten-lookup limit is a slow-motion failure: nothing breaks the day you cross it, and by the time you notice, some of your mail has been quietly failing for a while. Check your real resolved-lookup count now, trim what you do not need, flatten the stable senders, and lean on aligned DKIM for the rest. That cleanup is worth the hour: it is the difference between SPF that passes and SPF that silently does not.
Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker that expands your includes and shows the real lookup count. I wrote up the fixes in more detail here if you want to work through your own record.
Top comments (0)