How to Fix SPF Records Exceeding the 10 DNS Lookup Limit

Your SPF record is broken. Emails are bouncing or landing in spam, and when you check your DNS setup, everything looks fine. Then someone points out the problem: your SPF record has 14 includes, and the RFC says 10 is the maximum. Your mail provider rejects the message with a permerror. Another server silently softfails it. You have no idea which emails actually arrived.

This is a common operational problem. Organizations that use a CRM, a marketing platform, a help desk system, a cloud email provider, and their own mail servers can quickly accumulate more third-party includes than the SPF specification allows. Here is what the limit actually means and what your options are.

What the 10 DNS Lookup Limit Actually Is

RFC 7208 Section 4.4 defines how many DNS queries an SPF checker is required to perform before giving up. The rule: when evaluating an SPF record, the total count of DNS lookups triggered by mechanisms like include:, mx:, a:, and ptr: must not exceed 10.

If it does, the result is a permanent error (permerror). Receiving mail servers handle permerror differently. Some treat it as a softfail. Others reject the message outright. The outcome is inconsistent and unpredictable, which makes this a real operational problem, not just a technical curiosity.

The key point is this: every include mechanism triggers a DNS lookup. If that included domain has its own includes, those count too. Nested includes stack toward the parent domain's 10-lookup budget. A single include that points to a large email service provider can represent 5 or more lookups on its own. Each one comes out of the same 10-lookup pool.

Signs Your SPF Record Is Hitting the Limit

You will not always get a clear error message. Watch for these signals:

Email rejections or bounces with no clear reason
Receiving servers marking messages as spam despite valid DKIM and DMARC
SPF checks returning neither pass nor fail in your authentication reports
DMARC reports showing SPF failures for legitimate sending sources

If you use many SaaS tools that send email on your behalf, you are at risk. The 10-lookup ceiling is easy to breach once your sender portfolio grows beyond a handful of services.

How to Count Your Current SPF Lookups

Before you can fix the problem, you need to know where you stand. You can count SPF lookups manually using dig.

For each mechanism in your SPF record, look it up:

dig +short TXT yourdomain.com

Then for each include:, resolve that domain:

dig +short TXT include:_spf.google.com

Count every mechanism that triggers a DNS lookup: include:, mx:, a:, ptr:, and exists:. The all, ip4, ip6, and exp modifiers do not count as lookups.

If your total exceeds 10, you need to reduce the count.

Option 1: SPF Flattening

SPF flattening means replacing include: mechanisms with their resolved IP addresses, then removing the includes.

Instead of:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

You look up each included domain's IP ranges and write them directly:

v=spf1 ip4:209.85.192.0/19 ip4:198.61.0.0/24 ip4:198.89.0.0/24 ~all

The advantage: zero DNS lookups for those entries. The flattened record is evaluated in a single pass.

The disadvantage: IP ranges change. Third-party email providers rotate infrastructure. A flattened SPF record that is not updated becomes stale and will eventually break your email. You need a process to refresh flattened records periodically.

Some providers publish IP ranges specifically for this purpose. Google, for example, publishes its SPF IP ranges publicly. Others do not make this easy.

Option 2: Consolidate Redundant Includes

Look at your SPF record and check which includes are actually sending mail for you. Many organizations include services they no longer use, or include the same parent domain multiple times through different child paths.

For example, if you have:

v=spf1 include:_spf.google.com include:us._spf.google.com ~all

The us._spf entry is redundant. Google aggregates everything into _spf.google.com.

Audit your includes. Remove anything that is not actually sending mail. Combine multiple includes of the same parent domain into a single include. This is the lowest-effort fix if the problem is not severe.

Option 3: Subdomain Delegation

Instead of loading all your third-party senders into your main SPF record, delegate a subdomain to each service provider. Each subdomain has its own SPF record with its own 10-lookup budget.

Your main domain SPF record stays lean:

v=spf1 mx -all

Your CRM sends from crm.yourdomain.com. Your marketing platform sends from marketing.yourdomain.com. Each subdomain has its own SPF record:

v=spf1 include:sendgrid.net ~all   (on crm.yourdomain.com)
v=spf1 include:mailgun.org ~all   (on marketing.yourdomain.com)

This approach scales well. Adding a new sender does not force you back into the lookup limit problem. The tradeoff is that each sending subdomain needs its own DNS setup and its own subdomain configured with your provider.

Option 4: The redirect Modifier

The redirect modifier lets you point one domain's SPF record to another domain's SPF record. This is useful when multiple domains share the same mail-sending infrastructure.

v=spf1 redirect=_spf.example.com

If example.com and example.net use the same email provider, you can set example.net's SPF record to redirect to example.com's record. This consolidates management. However, redirect does not reduce lookup count if the target record also has many includes. It is useful for consistency, not for solving the lookup limit problem directly.

How to Monitor SPF Health Over Time

Fixing the lookup limit is not a one-time event. Email infrastructure changes. Providers add new IP ranges. Services rotate hosting providers. Your SPF record that is valid today can exceed the lookup limit next month.

You need ongoing visibility into your SPF health.

DMARCFlow monitors your SPF record and alerts you when your configuration is approaching the 10-lookup ceiling. It flags changes to your SPF infrastructure and can notify you when a new third-party sender would push you over the limit before that causes a permerror and email failures. This operational visibility turns a reactive problem into something you manage proactively.

Frequently Asked Questions

What happens if my SPF record exceeds 10 lookups?

The receiving mail server returns a permanent error (permerror). Different mail servers handle this differently: some treat it as a softfail, some reject the message, and some ignore the SPF result entirely. The result is inconsistent email delivery.

Can I exceed the 10-lookup limit by using a different mechanism?

No. The limit applies to all DNS lookups triggered during SPF evaluation, regardless of mechanism. mx:, a:, ptr:, include:, and exists: all count. Only mechanisms that do not trigger DNS queries (all, ip4, ip6, exp, redirect) are excluded from the count.

Is there an official way to request more than 10 lookups?

No. RFC 7208 specifies 10 as the required maximum. Mail servers are not required to perform more lookups. There is no mechanism to override or extend this limit.

How often should I update a flattened SPF record?

Check your third-party providers' IP ranges monthly at minimum. Many providers publish change logs or RSS feeds for their sending infrastructure. Some providers, like Google, have stable IP ranges that change rarely. Others, like some marketing automation platforms, rotate infrastructure frequently. The risk with flattening is that a provider can add new IP space without notifying you, and your static record silently stops matching their new infrastructure.

Can DMARCFlow help with SPF lookup monitoring?

Yes. DMARCFlow tracks your SPF record configuration over time and alerts you when your record is approaching the 10-lookup ceiling. It also monitors for unexpected changes to your SPF infrastructure, which helps you catch problems before they cause email rejections.