SPF Too Many DNS Lookups: How to Fix the 10-Lookup Limit

An SPF record can look perfectly valid and still fail authentication. One of the most common reasons is exceeding the SPF DNS lookup limit.

SPF allows no more than 10 DNS-querying terms during an SPF evaluation. If evaluation goes beyond that limit, the receiving server must return an SPF permerror.

The problem often appears as organizations add more:

• Email platforms
• CRMs
• Support systems
• Transactional email providers
• Other third-party senders

Fortunately, the issue can usually be fixed if you identify which mechanisms consume lookups, remove unnecessary senders, and restructure the SPF configuration without accidentally breaking legitimate email.

Key Takeaways

• SPF evaluation is limited to 10 DNS-querying terms.
• include, a, mx, ptr, exists, and redirect can count toward the limit.
• Nested SPF records count too, so four visible include: entries can still result in more than 10 lookups.
• ip4, ip6, and all do not consume the 10-lookup allowance.
• Exceeding the limit produces an SPF permerror.
• The safest fix is usually to remove unused sources, reduce unnecessary DNS-dependent mechanisms, and restructure sending where necessary.

The 10-Lookup Limit Is Slightly More Complicated Than It Sounds

 
It is commonly called the “10 DNS lookup limit,” but technically, SPF does not simply count every DNS packet exchanged.

RFC 7208 limits the number of SPF mechanisms and modifiers that cause DNS queries during evaluation.

The limit also applies across recursive processing, including:

• SPF records reached through include
• Nested include mechanisms
• redirect processing
• Other DNS-dependent SPF mechanisms

That distinction matters because simply counting the number of include: statements visible in your primary SPF record may give you the wrong answer.

Which SPF Mechanisms Count Toward the DNS Lookup Limit?

 
The following SPF terms can consume the lookup allowance:

SPF Mechanisms That Count Toward the 10-Lookup Limit

The ptr mechanism should generally not be used in newly designed SPF records. RFC 7208 explicitly says it should not be published because more reliable alternatives are available.

There are also additional processing restrictions around mechanisms such as mx and ptr. For example, SPF limits the number of address records that can be queried while evaluating individual MX records.

Why Nested Includes Cause SPF Lookup Problems

 
The most common mistake is counting only the mechanisms you can see in your own DNS record.

Suppose your SPF record contains:

v=spf1 include:spf.provider-a.com include:spf.provider-b.com include:spf.provider-c.com -all

At first glance, this appears to require only three DNS-dependent mechanisms.

However, each include can point to another SPF record containing additional:

• include
• a
• mx
• exists
• redirect

If spf.provider-a.com contains three more include mechanisms, and those records reference still more SPF records, those DNS-querying terms become part of the same evaluation budget.

This is why SPF records can exceed the limit even when the top-level record contains only a few entries.

A Broken include Can Cause PermError Too

 
Nested records do not only create a risk of exceeding the 10-lookup limit. They can also break independently.

For example, your SPF record contains:

include:spf.vendor.example

If that domain stops publishing an SPF record, the recursive SPF evaluation returns none. For an include mechanism, RFC 7208 maps that result to permerror.

The query itself is a void lookup, but the include's none result already produces permerror, so the two-void allowance never comes into play here.

That creates another version of the “we didn't change anything” problem: your own SPF record can remain untouched while a third party changes or removes the record you depend on.

What Happens When SPF Exceeds 10 DNS Lookups?

 
Once the permitted number of DNS-querying terms is exceeded, SPF evaluation returns:

permerror

A permanent error means the receiver could not successfully evaluate the SPF configuration according to the SPF specification.

What That Means in Practice

An SPF permerror does not necessarily mean every receiver will immediately reject the message.

Receiving systems determine how individual authentication results affect message handling.

However, it does mean that:

• SPF cannot provide a successful pass for that evaluation path.
• Authentication reliability is reduced.
• Deliverability problems may become more likely.
• SPF cannot provide the aligned SPF pass needed for DMARC.

DMARC can still pass if a valid aligned DKIM signature succeeds, because DMARC allows either aligned SPF or aligned DKIM to establish a pass.

How to Check Your SPF DNS Lookup Count

 
The first step is to analyze the full SPF dependency chain, rather than simply counting entries manually.

Check:

• Your primary SPF record
• Every include it references
• Additional SPF records referenced by those includes
• a, mx, exists, and redirect mechanisms
• Unused or duplicate mechanisms
• DNS queries that return no answer or a Name Error (void lookups, limited to two)

DMARKOFF's SPF Checker can automatically resolve an SPF record, calculate its DNS lookup usage, flag duplicate includes, detect ptr, check the two-void-lookup threshold, and show how much room remains before reaching the limit.
 
Run SPF Check
 
This is considerably safer than counting only the mechanisms visible in the top-level TXT record.

How Much SPF Headroom Do You Have?

 
Passing an SPF check today does not necessarily mean your configuration is safe.

There is an important difference between an SPF record that currently requires four DNS-querying terms and one that requires nine. Both are technically below the limit, but the second configuration has almost no headroom left.

Headroom is basically the distance between your current expanded SPF lookup usage and the hard limit of 10.

For example:

• 4 lookups: 6 lookups of headroom
• 7 lookups: 3 lookups of headroom
• 8 lookups: 2 lookups of headroom
• 9 lookups: only 1 lookup of headroom
• 10 lookups: no room for additional DNS-querying terms

The important part is that you do not completely control this number.

When you add:

include:spf.vendor.example

you depend on the SPF policy published by that vendor. The provider can later change its own record by adding another include, migrating to different infrastructure, or restructuring its sending architecture.

Your DNS record does not have to change for your total SPF lookup usage to change.

A configuration that expands to nine lookups today could therefore exceed the limit later because one of your providers modifies a nested record. This is why checking whether SPF is simply “valid” is not always enough. You also need to know how close the configuration is to the limit and how much of that lookup budget is controlled by third parties.

The SPF specification sets 10 as the protocol limit, not eight. However, organizations may choose to treat eight lookups as an operational warning threshold so there is some buffer for changes in external SPF records. The closer you operate to 10, the more easily a provider-side change can turn a valid configuration into permerror.

This is also why SPF should be monitored over time rather than checked only when the record is initially configured.

For a deeper look at why third-party SPF records can change your lookup count without anyone touching your DNS, read “Your SPF record is valid today. That means nothing.”

How to Fix the SPF 10-Lookup Limit Error

 

1. Remove Email Services You No Longer Use.

 
Start with an inventory of every platform authorized in SPF. Organizations frequently accumulate entries for:

• Old email marketing tools
• Previous help desk systems
• Retired CRMs
• Former transactional email providers
• Migration tools
• Services that no longer send email

If a service no longer sends mail using your domain's SPF identity, its SPF authorization usually no longer belongs in the record.

Removing one obsolete include can sometimes eliminate several nested DNS-querying terms.

2. Remove Duplicate Mechanisms.

 
Check whether the same provider or domain is referenced more than once.

For example:

v=spf1 include:spf.vendor.com include:spf.vendor.com -all

The duplicate does not provide additional authorization. It only adds unnecessary complexity.

Also check whether different entries ultimately authorize the same infrastructure.

3. Examine Nested Includes.

 
An SPF record such as:

include:spf.vendor.com

may appear to consume only one lookup-generating term at the top level, but the referenced SPF policy can contain its own:

• include
• a
• mx
• exists
• redirect

Follow the entire chain.

This is particularly important with SaaS providers because their SPF configuration can change over time. A record that previously stayed below the limit may cross it after a provider changes its own SPF policy.

4. Replace DNS-Dependent Mechanisms Where Appropriate.

 

If you directly control stable sending IP addresses, using ip4 or ip6 can be more efficient than using unnecessary a or mx mechanisms.

For example:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 -all

The ip4 mechanisms do not consume the SPF 10-term lookup allowance.

However, do not replace a third-party provider's include with a list of IP addresses simply to reduce lookups unless you know those addresses are stable and you have a reliable way to keep them updated.

Many email providers change or expand their sending infrastructure. Hard-coding a temporary IP list can cause legitimate mail to fail SPF later.

5. Avoid Unnecessary mx and a Mechanisms.

 
Records are sometimes built with broad mechanisms such as:

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

even though the domain's web server or inbound MX servers never send outbound mail.

In that case, a and mx add DNS-dependent mechanisms without providing any useful authorization.

A better rule is simple:

• Authorize only infrastructure that actually sends mail.
• Remove mechanisms that do not correspond to real outbound senders.

6. Do Not Create a Second SPF Record.

 
A common but incorrect workaround is splitting a large SPF policy into two TXT records:

v=spf1 include:provider-a.example -all

v=spf1 include:provider-b.example -all

This does not increase the lookup allowance.

Publishing multiple SPF records at the same domain can itself cause SPF evaluation errors.

All authorization for one SPF identity needs to be represented through a valid SPF configuration, not several competing v=spf1 records.

7. Consider Separating Email Streams Across Subdomains.

 
Large organizations often have many independent sending services, including:

• Corporate email
• Marketing platforms
• Transactional systems
• Support tools
• Billing systems

Instead of forcing every service into one SPF record, it can be useful to configure different envelope-sender or return-path subdomains.

For example:

• mail.example.com
• marketing.example.com
• transactions.example.com

Each domain can maintain the SPF policy required for its own sending infrastructure.

This should be implemented at the email-provider level rather than simply creating arbitrary DNS records. The provider must actually use the relevant domain as the SMTP MAIL FROM identity for SPF to evaluate it.

If DMARC is in use, remember that the SPF-authenticated MAIL FROM domain also needs appropriate alignment with the visible From domain.

Under relaxed DMARC alignment, subdomains that share the same Organizational Domain can align. Strict alignment requires identical domains.

8. Be Careful With SPF Flattening.

 
SPF flattening converts some DNS-dependent authorization into explicit ip4 or ip6 mechanisms.

In theory, this can dramatically reduce DNS lookups because direct IP mechanisms do not count toward the 10-term limit.

However, static flattening creates an important maintenance problem:

• Third-party email providers can change their sending IP ranges.
• A flattened SPF record can become outdated.
• Legitimate messages can begin failing SPF if the record is not updated.

For example, if you manually flatten:

include:spf.provider.example

into today's IP addresses and the provider changes those addresses next month, legitimate messages could start failing SPF.

For that reason, flattening should not be treated as a one-time copy-and-paste fix.

Prefer reducing unnecessary authorization first. If flattening is necessary, make sure the resulting IP data can be kept synchronized with the provider's infrastructure.

Don't Forget the SPF Void-Lookup Limit

 
The 10-lookup limit is not the only DNS-related SPF restriction. RFC 7208 also recommends limiting void lookups to two.

A void lookup occurs when a DNS query returns:

• No relevant answer, or
• A DNS “Name Error” response

Exceeding the recommended limit can also result in permerror.

This is another reason an SPF checker should evaluate actual DNS behavior rather than only count the visible mechanisms in a TXT string.

Verify the Fix

 
After modifying the SPF record:

1. Allow the DNS update to propagate according to its TTL.
2. Recheck the published SPF TXT record.
3. Recalculate the complete lookup chain.
4. Confirm there is only one applicable SPF record.
5. Send test messages through each legitimate email service.
6. Check SPF, DKIM, and DMARC results in the message headers.
7. Continue monitoring authentication results after the change.

After an SPF update, DMARKOFF can help verify the SPF configuration and, through DMARC reporting, provide visibility into legitimate sources that are still failing authentication.
 
Start 14-day Free Trial
 
That is particularly useful before removing an include, because DMARC data can help determine whether the associated source is genuinely inactive or is still sending mail on behalf of the domain.

Conclusion

 
The SPF 10-lookup limit becomes difficult to manage when a domain accumulates multiple third-party senders.

The main challenge is that nested include mechanisms can consume far more of the lookup budget than the top-level SPF record suggests.

To resolve the issue:

• Audit the complete SPF chain.
• Remove unused and duplicate sources.
• Avoid unnecessary DNS-dependent mechanisms.
• Restructure large sending environments when needed.
• Be cautious with SPF flattening.
• Never use multiple SPF records as a workaround.

Most importantly, test the final configuration against the entire recursive SPF evaluation, not just the TXT record you see in your DNS dashboard.

FAQ