The SPF ten-lookup limit, and how to stay under it

RFC 7208 caps the number of DNS-querying terms in a single SPF evaluation at ten. The cap exists to stop SPF being used to amplify traffic at a third party: without it, one message could trigger an unbounded chain of lookups against someone else's nameservers. It is a hard limit, and crossing it does not degrade your record gracefully. It breaks it.

What counts, and what does not

Every include, a, mx, ptr and exists mechanism uses one lookup, as does a redirect modifier. Crucially, the count is recursive: an include uses one lookup plus however many the record it points at uses, and that record's includes in turn.

• Counted: include, a, mx, ptr, exists, and the redirect modifier.
• Free: ip4 and ip6, which need no resolution at all.
• Free: the all mechanism.
• Free: the initial lookup of your own SPF record.

The mx mechanism uses a second lookup worth knowing about: resolving the MX record is one lookup, and then each MX host returned must be resolved to its addresses, each of which counts. A domain with five mail exchangers can spend six lookups on a single mx mechanism.

Why it creeps up on you

Nobody writes an over-limit record deliberately. It happens because a single include hides several more, and the lookup count is invisible in the text you are looking at.

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com -all
        └ 4 lookups        └ 3 lookups      └ 2 lookups

That record looks modest. It is one mechanism away from breaking. Add a CRM, a helpdesk and a billing system, each of which arrives with its own setup instructions saying to add one more include, and you cross ten without anything looking excessive.

Worse, the failure is retroactive and silent. A provider can restructure their own SPF record, adding an include on their side, and push you over the limit without you changing anything. Your record was fine on Monday and is a permerror on Tuesday.

The second limit nobody mentions

There is a quieter cap alongside the famous one: at most two void lookups, meaning queries that return NXDOMAIN or no records. A single typo in an include, or a vendor domain that has been decommissioned, produces a void lookup. Three of them is a permerror on its own, regardless of how far under ten you are.

Fixing an over-limit record

Work through these in order. The early steps cost nothing and are reversible; the last one is powerful and carries an ongoing obligation.

1. Remove senders you no longer use. This is almost always the biggest single win, and it is free. Your DMARC reports will tell you which includes have sent no mail in months.
2. Drop a redundant mx or a mechanism. Many domains authorise their own mail exchangers out of habit, but inbound servers usually send no outbound mail.
3. Replace an include with the ip4 ranges behind it, but only where the provider publishes stable, documented ranges and commits to announcing changes. If they do not, you have traded a lookup for a silent outage later.
4. Move some senders onto a subdomain with its own SPF record. Bulk and transactional mail on mail.example.com gets its own budget of ten, entirely separate from the root domain's.
5. Flatten the record: resolve every include down to its addresses and publish the result as ip4 and ip6 mechanisms, which use no lookups.

The subdomain approach in step four deserves more attention than it usually gets. Splitting bulk mail onto its own subdomain gives you a separate lookup budget, a separate reputation, and the ability to set a different DMARC policy while you are still rolling out. Under relaxed alignment, which is the default, mail from mail.example.com still aligns with a From address at example.com, so nothing about your visible sending identity has to change.

Checking where you stand

Paste your domain into the SPF tool to get the mechanisms broken out with a running lookup count. If you are at eight or nine, treat that as over the limit: you have no headroom for a provider to restructure their record, and no room to onboard anything new. The SPF flattener resolves every source into a single hosted include with automated refresh, which is the durable version of step five.

Once you are comfortably under the cap, the next thing to get right is what the record says about unlisted senders.