Skip to content
Not the Junk Folder

What is the SPF 10-lookup limit and how do I fix it?

Scott Anderson · Last reviewed

Short answer

SPF evaluation is capped at ten DNS lookups, counting every include, a, mx, ptr, exists and redirect — including those nested inside other includes. Exceeding it produces a permanent error, and receivers discard your entire SPF record rather than the last mechanism. Nothing warns you; mail simply starts failing after you add one more tool.

Key facts

  • The limit is ten DNS-querying mechanisms per SPF evaluation, and it is a hard cap defined by the standard. RFC 7208 §4.6.4

  • Exceeding it produces a permerror, and the standard result is that SPF does not pass — the record is not partially applied. RFC 7208 §4.6.4

  • Lookups nested inside an include: count toward your total. A single include can consume five or more. RFC 7208 §4.6.4

  • ip4: and ip6: mechanisms cost nothing, because they require no DNS query. RFC 7208 §4.6.4

This is the most under-appreciated failure in email configuration, because of how it presents: everything works, you add one more perfectly ordinary tool, and unrelated mail starts landing in junk. Nothing in the interface of any product involved will mention DNS lookups.

The cap exists to stop SPF being used to amplify DNS traffic. Ten lookups per evaluation, and once a receiver hits eleven it stops and returns a permanent error.

Why counting your own record misleads you

Look at your SPF record and you might count four includes and conclude you're comfortably fine. But each include: points at someone else's record, which contains its own includes, and all of them count against your ten.

One large marketing platform's include can resolve to five or six lookups on its own. Two such platforms plus your mail host, and you're at the ceiling with three visible entries.

What over-the-limit looks like

Looks reasonable — is not

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com include:spf.protection.outlook.com a mx ~all

Five includes plus a and mx. Once nesting is expanded this is comfortably past ten, and the entire record is discarded.

The same senders, flattened where sensible

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.24 ip4:203.0.113.7 ~all

ip4: mechanisms cost zero lookups. Suitable for senders with stable, published IP addresses.

What counts against the ten

include:
One, plus everything inside it.
a and a:
One each.
mx and mx:
One each — and each MX host resolved counts too.
ptr
One, and it is deprecated. Remove it if you find it.
exists:
One each.
redirect=
One, plus everything in the record it points at.
ip4: and ip6:
Zero. This is the escape hatch.
all
Zero.

Four ways to get back under

In the order they're usually worth trying.

  1. 01

    Remove what you no longer use

    The fastest and safest win. Every business we audit has at least one include for a platform they stopped paying for. Old web hosts, a CRM from two systems ago, a mail filter removed during migration.

  2. 02

    Drop a and mx if they're redundant

    These are often left over from an era when your web server sent mail. If nothing sends from those hosts now, they're two lookups spent on nothing.

  3. 03

    Replace includes with ip4: where the vendor publishes stable addresses

    Zero-cost mechanisms. The trade-off is real: if the vendor changes IPs and you don't notice, that sender starts failing. Only do this where the addresses are documented as stable, and diarise a review.

  4. 04

    Use a subdomain for bulk sending

    The structurally correct answer. Send marketing from news.yourdomain.com with its own SPF record and its own ten-lookup budget, leaving your main domain lean. It also isolates your invoice deliverability from your newsletter's complaint rate.

How to tell if this is happening to you

A checker that expands nested includes will give you the real number. This site's checker counts the mechanisms visible in your own record and flags you when you're near the limit — deliberately conservative, because the true count after nesting is always higher than what you can see.

The other signal is behavioural: mail from one particular tool started failing shortly after you added a different, unrelated tool. That sequence is close to diagnostic.

Frequently asked

Does going over the limit break all my email?

It breaks SPF for all of it. If DKIM is properly configured, DMARC can still pass on the DKIM side, which is exactly why having both matters so much. Domains relying on SPF alone go from fine to failing with no intermediate state.

Is there a character limit too?

A single DNS TXT string is capped at 255 characters, though longer records can be split across multiple strings that receivers concatenate. The ten-lookup limit is the one that bites in practice.

Should I just use ip4: for everything?

No. It removes the vendor's ability to change infrastructure without breaking you, and it converts a working record into something that requires ongoing maintenance. Use it selectively, for senders with genuinely stable published addresses.

Do lookups reset for each recipient?

The limit applies per SPF evaluation, so every message is evaluated against the same ten-lookup budget. Being over the limit isn't intermittent — it fails consistently, for everyone.

Find out where your domain actually stands.

The checker reads your real records in a few seconds. The review works out whether they cover everything you send.