SPF 10-Lookup Limit and SPF Flattening

The SPF record looked fine for a year. Then you added a review platform, a second ESP for receipts, and the helpdesk. The next authentication test says permerror. Nothing was “hacked.” The record asked DNS more questions than SPF allows.

Last verified: 26 September 2026, against RFC 7208 section 4.6.4.

What the SPF 10-lookup limit counts

RFC 7208 limits SPF evaluation to 10 DNS lookups from mechanisms and modifiers that query DNS. include, a, mx, ptr, exists, and redirect do that. ip4 and ip6 do not. Lookups inside an include count as well. Ten vendors is not the limit. Ten lookups is the limit, and one vendor’s include can contain several. A record with only four include: lines can still exceed 10 lookups once the nested includes are counted. Whether yours does depends on how each vendor builds its record today, and vendors change that without telling you, so count the live record with the SPF record checker rather than the text you pasted.

A result over the limit is a permerror. It is not a soft fail you can shrug off, and it is not a pass. The short operational page is SPF hard fail. This page is the decision that page does not have room for: whether to flatten.

DMARC still has a second path. If DKIM is aligned and passes, DMARC can pass while SPF permerrors. That is why a campaign can “look authenticated” in one tool and fail SPF in another. Aligned DKIM is not a reason to leave the SPF record broken. The next receiver, or the next incident, will be the one that needed SPF. SPF, DKIM, and DMARC is the overview. Alignment is why a pass on the wrong domain still fails DMARC.

Multiple ESPs are how stores hit the limit

Marketing in Klaviyo, receipts in SES or another transactional tool, a support desk, a review app, and a leftover include from the ESP you migrated off last year. Each include is a lookup, and some of those includes exist so the vendor can change IPs without asking you to edit DNS.

That design is good until the sum crosses 10. The migration guide tells you to add the new sender before you cut over. It should also end with deleting the old include after the cutover is done. An include you no longer send through still costs a lookup on every message. SPF is not the only record a second sender touches: multiple DKIM selectors is the DKIM side of the same change.

When flattening helps, and when it creates the next outage

Flattening copies today’s IPs into your record so you stop paying the lookup. Use it when:

• You have already removed dead vendors and you are still over 10.
• You know which company owns each IP block you pasted in.
• You have a way to notice when that company publishes a new range.

Do not flatten as a permanent architecture. ESPs rotate addresses. A flattened record that was correct in March will start failing SPF, or fail to authorize the new path, when the include would have followed the change and your copy did not. The failure mode is quiet: mail keeps going out, SPF starts failing, and DMARC depends entirely on DKIM until someone looks.

Prefer this order:

1. Delete unused mechanisms.
2. Ask whether two tools can send under one include you already have.
3. Flatten the minimum set that remains, and date the change.
4. Rebuild on a schedule, or when a vendor’s IP notice arrives.

The SPF generator is useful for assembling the record. It does not know which includes are abandoned. You do.

Sources

• SPF, section 4.6.4, RFC 7208. The 10-lookup limit and permerror.
• DMARC, RFC 9989. DMARC can pass on aligned DKIM when SPF does not pass. The policy RFC does not raise the SPF lookup limit.