SPF 10 DNS Lookup Limit, Void Lookups and SPF Flattening

SPF limits each check to 10 DNS lookups. Every include, a, mx, ptr and exists mechanism, and the redirect modifier, counts toward that limit, including the ones nested inside the includes you reference. If evaluating your record takes more than 10, the receiver stops and returns a permanent error (permerror), and SPF fails. That can hit any of your mail, not just the service that pushed you over.

The limit comes from RFC 7208, the SPF specification, section 4.6.4: implementations "MUST limit the total number of those terms to 10," and exceeding it "MUST return permerror." Receivers aren't being picky. They're following the spec.

One wrinkle makes this hard to spot. Evaluation stops as soon as a mechanism matches the sending IP, so mail from a service listed early in the record may still pass while mail from services further down fails. Microsoft's documentation calls this out. An over-limit record often looks like it's "mostly working," which is why it can go unnoticed for months.

To see where you stand right now, run your domain through the SPF lookup counter. It expands every include and shows the running total.

Why the limit exists

Each lookup is a DNS query the receiving server has to make before it can decide whether to accept your message. Without a cap, a badly built (or malicious) SPF record could make a receiver chase hundreds of queries, which is a performance problem and a denial-of-service vector. Ten is the compromise.

What counts toward the 10

The part people miss is nesting. Here's a record that looks like it has four lookups:

v=spf1 include:_spf.example-mail.com include:spf.example-crm.com include:mail.example-helpdesk.net mx -all

But if _spf.example-mail.com itself contains three includes, and spf.example-crm.com contains two, the real count is 4 + 3 + 2 = 9 before you add anything else. One more tool and you're at permerror. You can't count this by eye; you have to expand the tree.

Void lookups: the second limit

RFC 7208 also says SPF implementations should limit "void lookups" to two. A void lookup is a DNS query that comes back empty: the name doesn't exist, or it exists but has no records of the type requested. Exceeding the limit is also a permerror.

Void lookups usually come from cleanup that didn't happen:

• An include: for a vendor you stopped using, whose SPF record has since been deleted.
• An a: or mx: pointing at a hostname that was decommissioned.
• A typo in an include domain.

The void limit is a "SHOULD" rather than a "MUST" in the spec, and the major mailbox providers don't publicly document how strictly they enforce it. Treat it as enforced. A dead include is worth removing anyway.

Other SPF limits worth knowing

• One SPF record per domain. If you publish two TXT records starting with v=spf1, the result is permerror. Merge them.
• 255-character strings. A single TXT string can hold at most 255 characters. Longer records are split into multiple quoted strings inside one TXT record, which receivers join without spaces. Most DNS consoles handle this for you; some don't.
• Keep it small. RFC 7208 says the whole record should fit in a 512-byte DNS response, and suggests staying under 450 octets.

How to get back under 10 lookups

Work through these in order. The first few are free and carry no risk.

1. Count first. Use the SPF lookup counter to see the full expanded tree and which includes cost the most.
2. Remove what you no longer use. Old ESPs, a CRM you migrated off, a trial tool from three years ago. This alone fixes a lot of records.
3. Remove includes that aren't needed. SPF checks the Return-Path (envelope sender) domain, not the From domain. If a service sends with its own Return-Path domain, or a custom one on a subdomain like bounce.example.com, its include in your root record does nothing. Check a real message's headers before removing anything: look for smtp.mailfrom in the Authentication-Results header. The header analyzer makes this quick.
4. Replace a, mx and ptr with ip4:/ip6:. If your MX hosts don't send outbound mail, mx is probably doing nothing useful. Drop ptr entirely.
5. Move senders to subdomains. Each domain gets its own 10-lookup budget. Put your marketing platform on news.example.com and your transactional mail on mail.example.com, each with its own SPF record and custom Return-Path. Under relaxed DMARC alignment, those still align with example.com.
6. Lean on DKIM. DMARC passes if either SPF or DKIM passes aligned. A service that signs with custom DKIM for your domain doesn't strictly need to be in your SPF record for DMARC to pass. Keep SPF accurate, but don't treat it as the only thing holding authentication together.
7. Flatten, if you must. See below.

SPF flattening: what it is and what it costs

Flattening means replacing include: mechanisms with the IP addresses they resolve to, so the receiver needs fewer queries:

Before: v=spf1 include:_spf.example-mail.com -all
After:  v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/25 -all

It works, and it can take a record from 14 lookups to two. The catch is that you're now responsible for keeping those IPs current. When the vendor adds a sending range, their published include updates instantly and your flattened copy doesn't. Mail from the new range fails SPF, and nobody gets told.

If you flatten:

• Flatten only the includes you need to, and leave stable, small ones alone.
• Use a service that re-resolves the includes on a schedule and updates your record automatically, or set a recurring check yourself.
• Watch the record size. Big providers publish a lot of ranges, and a flattened record can blow past the 255-character string and 512-byte limits.

Flattening is a workaround. Removing unused includes and moving senders to subdomains fix the underlying problem.

How to confirm it's fixed

Re-run the SPF lookup counter and check that the total is 10 or under with no void lookups. Then send a test message from each sending service to a mailbox you control and confirm spf=pass in the Authentication-Results header. The SPF, DKIM and DMARC checker will also flag syntax errors and duplicate records.

How to keep it from coming back

Over-limit records almost never start that way. They get there one include at a time, as different teams add tools. Make an SPF check part of onboarding any new sending service, keep a short list of which include belongs to which vendor and who owns it, and recount whenever the list changes. And if you're on DMARC, your aggregate reports will show SPF starting to fail across every source at once, which is the signature of a permerror. See DMARC fail: why it fails and how to fix it.

When to get help

If you've removed everything you can and are still over 10, or you're not sure which includes are safe to drop, a second pair of eyes on the record and your sending setup is cheaper than breaking SPF for the whole domain.

FAQ

What happens if my SPF record has 11 lookups?

Once a receiver reaches the 11th lookup while evaluating your record, it stops and returns permerror, so SPF fails. Senders matched early in the record may still pass, which makes the problem look intermittent. Anything relying on SPF for DMARC fails DMARC too.

Do ip4 and ip6 count toward the SPF lookup limit?

No. They don't require a DNS query, so they don't count. Neither does all. Only include, a, mx, ptr, exists and redirect count.

Can I use more than one SPF record to get around the limit?

No. Two SPF records on the same domain is itself a permerror. Use subdomains instead; each one has its own record and its own 10-lookup budget.

Is SPF flattening safe?

It's safe as long as something keeps the flattened IPs in sync with your vendors' published ranges. A flattened record nobody maintains will eventually fail when a vendor adds infrastructure.