This is the most frustrating failure in email security, because it happens at the exact moment you are trying to do the right thing. You spot a legitimate sender in your DMARC reports, you dutifully add it to your SPF record, and the next day part of your mail stops arriving. Nothing failed visibly. You simply crossed a limit nobody told you about.
The rule, and why it exists
The SPF specification caps evaluation at ten DNS lookups. Beyond that, the check stops and returns permerror.
The limit is not arbitrary: without it, a maliciously crafted SPF record would make a receiving server run hundreds of DNS queries for every message. It is an anti-amplification measure, and it is not negotiable.
What counts, and what does not
This is where everyone gets it wrong. The limit is not on how many mechanisms you write, but on the lookups they trigger.
| Mechanism | Cost | Note |
|---|---|---|
include: | 1, plus the cost of what it includes | Recursive: this is where it blows up |
a | 1 | |
mx | 1, plus one per returned server | Sneaky: ten servers, ten lookups |
exists: | 1 | |
redirect= | 1, plus the cost of the target | |
ip4: ip6: | 0 | No lookup at all: this is the way out |
all | 0 |
The trap is include:. A single include for a large mail provider can consume three or four on its own, because it includes further records itself. Three providers of that kind and you are at the limit without having written ten mechanisms.
There is another twist: includes change without telling you. A provider reorganizing its infrastructure can add an include inside its own record. Your SPF was at nine yesterday, it is at eleven today, and you touched nothing.
How to know where you stand
Count before you edit, not after. An SPF checker gives you the effective total by expanding every include. Three thresholds are worth remembering:
- 8 or below: you have room.
- 9 or 10: you are on borrowed time. The next provider reorganization tips you over.
- 11 or more: it is already broken. Check immediately whether your flows still pass through DKIM.
How to come back down
Four levers, in the order we apply them.
1. Remove what no longer sends
The highest-yield lever, and the one everybody skips. On a record accumulated over years, a third of the includes belong to services that no longer send anything. The DMARC reports say so: a source absent from every report for three months has no business in your SPF.
2. Move to DKIM instead of SPF
The real fix. A provider that signs your messages with DKIM using your domain no longer needs to be in your SPF at all: DMARC passes as soon as either mechanism aligns.
This is the only lever that addresses the cause. The other three buy time.
3. Replace an include with its IP ranges
ip4: costs no lookup. A provider whose infrastructure is stable and documented can be written out directly as address ranges.
4. Split your sending domains
The structural approach, and the only one that holds at scale. Marketing sends from news.your-domain.com, application notifications from app.your-domain.com, human mail from the main domain.
Each subdomain gets its own record, and therefore its own ten lookups. The benefit goes beyond the technical limit: a poorly rated marketing campaign no longer drags down the reputation of the domain carrying your commercial conversations.
The mistake not to make
Never replace -all with ~all or ?all to "let mail through". You fix nothing: you publicly announce that anyone may send in your name. The permerror is still there, and you gave up the protection as a bonus.