Each include, a, mx, ptr, exists, and redirect counts toward the 10-lookup ceiling, and includes count transitively. Once you exceed it, legitimate senders can fail SPF, but DKIM-aligned mail survives.
SPF has a numeric ceiling inside every SPF record: a receiver must not exceed 10 DNS lookups while evaluating an SPF policy. Hit eleven, and the result is permerror. In DMARC terms, that is equivalent to no SPF pass at all.
This is the common reason a domain that had SPF working for years suddenly starts failing. Nothing changed locally. Your ESP added another include to its SPF chain, your record moved from nine lookups to eleven, and legitimate senders broke overnight.
How to count
These mechanisms cost one DNS lookup each:
include:amxptr, which should not be used in SPFexists:redirect=
The mechanisms that do not cost a lookup are ip4:, ip6:, and all. They are either literal CIDR ranges or a terminal mechanism, so the receiver does not need another DNS query to evaluate them.
The trap is that include: is transitive. If you include _spf.google.com, that record itself includes Google netblock records. Each one counts against your budget. A single Google Workspace include can consume four lookups before you add any other sender.
v=spf1
include:_spf.google.com (cost: 4)
include:spf.mandrillapp.com (cost: 2)
include:mail.zendesk.com (cost: 3)
include:sendgrid.net (cost: 2)
include:spf.protection.outlook.com (cost: 2)
~allThat record is at 13 lookups. Receivers that evaluate it correctly return permerror, and SPF stops authorizing senders that looked fine in the DNS editor.
How to actually check your count
dig +short TXT example.com shows the top-level record, but counting by hand is unreliable because the nested includes matter. Use a checker that walks the tree and shows the expanded count.
- Use a tool that expands nested include and redirect records.
- Treat eight or nine lookups as a warning state, not as a clean bill of health.
- Re-check after onboarding any ESP, CRM, billing system, or outbound gateway.
- Prefer trended monitoring so a vendor-side expansion is visible before it reaches ten.
The warning band matters because vendor records expand silently. Sitting at nine lookups is sitting on a tripwire. Sitting at seven gives you headroom for the next provider-side change.
Flattening options and trade-offs
There are four reasonable ways out of an overflowing SPF record.
Drop senders that do not need SPF. Most modern ESPs sign with DKIM using a CNAME-delegated key. If they sign correctly with an aligned domain, DMARC can pass on DKIM alone. They do not always need to stay in SPF.
Use a flattening service. Flattening resolves the include chain and publishes the resulting IP ranges as ip4: and ip6: mechanisms. That reduces lookup cost, but it turns vendor IP changes into an operational dependency. If the flattened record is not refreshed, legitimate mail can fail later.
Use SPF macros. Macro-based SPF can split logic in advanced ways, but it is fragile and rarely worth deploying for ordinary SaaS and business domains.
Move senders to subdomains. Marketing can send from mkt.example.com, transactional mail from txn.example.com, and human mail from example.com. Each domain gets a smaller SPF record. The trade off is migration work across every vendor.
Why this matters more now
The 10-lookup ceiling became more painful as sender estates grew. A domain can easily have Google Workspace, Microsoft 365, several transactional ESPs, a support desk, a marketing platform, and sales tools all asking to be included in one SPF record.
AI outbound tools add another pressure point. Many of them ask for SPF authorization so they can send as sales or recruiting users. Each one may add one to three lookups. The right first question is whether the sender can authenticate with aligned DKIM instead.
The DKIM safety lecture
This whole cleanup assumes DKIM is working. If a sender is SPF-only, then failing SPF means failing DMARC. The order should be:
- Every sender signs DKIM with a domain-aligned key.
- SPF lists senders as a backup path where it is useful.
- If SPF starts overflowing, remove senders that are already passing DMARC through DKIM.
Treating SPF as the primary authentication mechanism and DKIM as the backup is inverted for most setups. SPF is useful, but it is fragile at the exact moment modern sender estates become large.
Where DMARCify fits
DMARCify shows each domain's SPF posture alongside observed DMARC results, so the lookup count is not a one-time audit artifact. The useful signal is the combination: which senders are SPF-only, which ones already pass DKIM alignment, and which records are close enough to the limit that the next vendor change can break them.