SPF 10-DNS-Lookup Limit: What Counts and How to Fix It

What is the SPF 10-lookup limit?

SPF lets a domain specify which mail systems are authorized to send using that domain's SMTP MAIL FROM identity.

Some SPF mechanisms require DNS queries to evaluate. RFC 7208 limits the total number of certain DNS-query-causing SPF terms to 10 during evaluation. The purpose is partly to prevent SPF evaluation from creating excessive DNS load.

The important part is this:

The limit is not 10 include: statements. It is not 10 raw DNS packets. It is a limit on the evaluated DNS-query-causing SPF terms across the recursive policy tree.

When SPF follows an include: into another SPF record, qualifying terms inside that record continue consuming the same lookup budget. The counter does not simply reset for every include.

What counts toward the SPF 10-lookup limit?

These are the terms you need to watch:

These distinctions come directly from SPF's processing limits in RFC 7208.

There are additional SPF DNS safeguards too. For example, RFC 7208 recommends limiting so-called void lookups—DNS queries that return NXDOMAIN or no usable data—to two.

Why counting include: statements isn't enough

Consider this SPF record:

v=spf1 include:a.example include:b.example mx -all

At first glance, you might count two includes plus mx and assume the record uses only three lookups.

But suppose a.example contains:

v=spf1 include:c.example -all

And b.example contains:

v=spf1 a:mail.b.example exists:spf-check.b.example -all

On an evaluation path that reaches all of those terms, the count becomes:

include:a.example       1
include:c.example       1
include:b.example       1
a:mail.b.example        1
exists:...              1
mx                      1
                        ─
Total                   6

The original record still contains only two visible includes.

This is why an SPF record can look short while the complete evaluation tree is already approaching—or exceeding—the limit.

There's another complication: the exact number can depend on the evaluation path. SPF evaluates mechanisms in order and stops when a mechanism matches. A redirect= is only processed if the preceding mechanisms do not produce a match. Different senders can therefore traverse different parts of the same SPF policy.

What happens when SPF exceeds 10 lookups?

The result is permerror.

This is different from the result produced by the qualifier at the end of your record.

For example:

-all

means SPF returns fail when that mechanism is reached.

~all

means SPF returns softfail.

But exceeding the lookup limit works differently:

11th DNS-query-causing term
            ↓
        permerror

It does not work like this:

11th lookup
     ↓
continue evaluating
     ↓
~all
     ↓
softfail

Once the processing limit is exceeded, the SPF policy cannot be evaluated normally.

That doesn't mean every receiver will automatically reject the message. SPF defines the authentication result; the receiving mail system ultimately decides how to treat it.

So a claim such as “SPF PermError means your email will bounce” is too absolute.

Microsoft, for example, explicitly documents more than 10 SPF DNS lookups as a cause of permerror, while final handling can also depend on the receiver's broader authentication and anti-spam systems.

Why companies accidentally exceed the SPF limit

A common cause is simply adding more services over time.

A business might start with its primary email provider and eventually authorize:

Microsoft 365 or Google Workspace
CRM
marketing platform
support system
transactional email provider
billing platform
website mail
security gateway

Each vendor may tell you to add another include: to SPF.

The resulting record might look reasonable:

v=spf1
include:mail.example
include:crm.example
include:marketing.example
include:support.example
~all

But each included policy can contain additional DNS-query-causing terms.

That's how four or five visible includes can become more than 10 evaluated terms. The research found accumulated SaaS authorization to be a common practical failure pattern, and Microsoft specifically identifies newly added CRM and marketing systems among common SPF troubleshooting scenarios.

Before changing your SPF record, check the live record and its dependencies with the SPF Checker rather than assuming the visible number of includes is the real lookup count.

How to fix “SPF too many DNS lookups”

The goal isn't simply to make the number smaller. You need to reduce DNS-dependent authorization without accidentally removing legitimate senders.

A sensible order is:

1. Identify every legitimate sending service. Determine what actually sends mail using the affected MAIL FROM or return-path domain.
2. Remove obsolete includes. If an old CRM, newsletter platform, help desk, or other service no longer sends mail for the domain, remove its authorization instead of optimizing around it.
3. Remove unnecessary mechanisms. Don't keep a, mx, or other lookup-causing mechanisms unless the infrastructure they authorize genuinely sends mail.
4. Separate independent sending streams where appropriate. Marketing and transactional providers may support custom return-path domains or subdomains with their own SPF policies.
5. Configure DKIM and DMARC correctly. DKIM gives legitimate mail another authentication path and is particularly important because SPF is vulnerable to forwarding.
6. Consider SPF flattening only after simpler fixes.
7. Retest after every significant change.

This is preferable to immediately flattening a complicated SPF record.

Should you flatten your SPF record?

Sometimes—but not automatically.

SPF flattening replaces DNS-dependent authorization with literal IP ranges.

For example, a provider might normally be authorized using:

include:spf.provider.example

A flattened policy might instead contain addresses such as:

ip4:192.0.2.0/24
ip6:2001:db8::/32

Because ip4: and ip6: don't consume the 10-term lookup budget, flattening can dramatically reduce SPF lookup usage.

But there's an important tradeoff.

With an include:, the provider controls its SPF record. If it changes sending infrastructure, it can update that record.

Once you copy the provider's IP ranges into your SPF record, keeping those addresses current becomes your responsibility.

A manually flattened record can therefore become stale and eventually authorize old infrastructure or fail to authorize new infrastructure.

The safer order is usually:

remove unused authorization → simplify the policy → separate independent mail streams → flatten selectively if still necessary.

Flattening makes the most sense when the underlying ranges are stable or when updates are reliably automated.

Using subdomains to reduce SPF complexity

Sometimes the root problem is that too many unrelated systems are sharing one SPF policy.

Instead of authorizing every service through:

example.com

a marketing provider might use a custom return-path such as:

bounce.marketing.example.com

That domain can have its own SPF policy.

This separates authentication infrastructure and gives different sending streams independent SPF lookup budgets.

However, don't move mail to subdomains without considering DMARC alignment. Under relaxed SPF alignment, a subdomain can align organizationally with the parent domain; strict alignment requires an exact match. DKIM should also be configured for important senders.

Does forwarding cause the SPF 10-lookup problem?

Not usually. Forwarding causes a different SPF problem.

SPF evaluates whether the connecting server is authorized for the envelope sender's domain. When a message is forwarded, the final receiver sees the forwarding server's IP—not necessarily one authorized by the original sender.

That means SPF can fail even though the original message was legitimate.

Adding arbitrary forwarding servers to the original sender's SPF record is generally not the solution.

Forwarding systems under your control can use Sender Rewriting Scheme (SRS) to rewrite the envelope sender. DKIM can also survive many forwarding scenarios, while ARC can provide receivers with authentication information from earlier in the message's path.

This is another reason email authentication should not rely on SPF alone.

Don't change ~all to -all just because you fixed the lookup count

Reducing SPF lookups and deciding whether to use ~all or -all are separate decisions.

There's an especially important 2026 consideration here.

The current DMARC specification, RFC 9989, notes that some receivers may act on an SPF -all failure early enough in the SMTP transaction that they reject the message before receiving the message body—and therefore before DMARC can evaluate an otherwise valid aligned DKIM signature.

Such an early rejection can also prevent the message from appearing in normal DMARC aggregate reporting because the receiver never received the From header needed for DMARC evaluation.

So don't treat this:

~all → -all

as the automatic next step after fixing an SPF lookup problem.

Fix the lookup problem first. Then evaluate your SPF qualifier as a separate authentication-policy decision.

How to check your SPF lookup count

You can retrieve the top-level SPF record yourself with tools such as:

dig +short TXT example.com

or:

nslookup -type=TXT example.com

But that only shows the published TXT data.

It does not automatically tell you the complete recursive SPF evaluation tree.

A useful SPF audit needs to follow nested include: and redirect= policies and account for other DNS-query-causing mechanisms reached during evaluation.

You should also inspect actual delivered messages for authentication results:

Authentication-Results:
    spf=pass
    dkim=pass
    dmarc=pass

That helps confirm how your real mail streams are authenticating—not just whether the DNS record looks correct.

Check your live domain with the InspectMyPage SPF Checker before and after making changes.

Bottom line

The SPF 10-lookup rule is easy to misunderstand.

It does not mean:

“You can have 10 includes.”

The more accurate rule is:

SPF permits up to 10 evaluated DNS-query-causing terms across the recursive evaluation, and exceeding the limit produces permerror.

For most domains, the best fix is not to flatten everything immediately. Remove obsolete senders, simplify unnecessary authorization, separate independent mail streams when practical, maintain DKIM and DMARC, and use flattening selectively when its maintenance tradeoffs make sense.