SPF DNS lookup limits

While an SPF record can look simple, evaluating it may require looking up other domains, and those domains may in turn reference more records.

To keep SPF checks reasonably fast and predictable, the SPF specification defines a few lookup limits (RFC 7208 section 4.6.4). If one of these limits is exceeded, mail servers following the specification will treat the SPF result as a permanent error.

In practice, a syntactically valid SPF record can still cause legitimate email to fail SPF authentication.

DNS lookup limit

The main limit is the 10 DNS lookups limit. When people say that an SPF record is exceeding the lookup limit, they usually refer to this limit.

This limit of 10 lookups applies to DNS queries caused by SPF terms inside the main record, but also by terms contained in any record discovered through the expansion of the record, such as through include directives.

This means that in theory even a simple SPF record with a single include directive could exceed this limit. Note that the initial TXT lookup to discover the main SPF record does not count toward this limit.

The terms in an SPF record that increase the count are the ones that require the SPF verifier to ask the DNS for more information:

• include
• redirect
• a
• mx
• exists
• ptr

On the other hand, the following mechanisms already contain the information needed to evaluate them and therefore do not count against the limit:

• ip4
• ip6
• all

For example, this record uses no DNS lookups during SPF evaluation because the allowed IP ranges are written directly in the record:

v=spf1 ip4:198.51.100.10 ip6:2001:db8::/32 ~all

This record, on the other hand, requires at least three DNS lookups:

v=spf1 a mx include:_spf.example.com ~all

One lookup comes from a, one from mx, and one from include:_spf.example.com.

The tricky part is that include can hide more lookups. For example, this record appears to have two lookups:

v=spf1 include:mail.example.com include:marketing.example.com ~all

But if the included records look like this, the count increases:

mail.example.com TXT "v=spf1 include:_spf.vendor.example ~all"

marketing.example.com TXT "v=spf1 include:send.vendor.example include:bounce.vendor.example ~all"

In this case, the total is already 5 lookups:

• include:mail.example.com
• include:_spf.vendor.example
• include:marketing.example.com
• include:send.vendor.example
• include:bounce.vendor.example

In practice, what matters is the whole SPF resolution chain, not only the first TXT record you publish. Tools such as DMARCwise help you see the full chain and calculate the DNS lookup limit for you.

Void lookup limit

A void lookup is a DNS lookup that returns no answers, either because the domain does not exist or because the response is empty.

SPF implementations should limit void lookups to 2. This limit is separate from the 10 DNS lookup limit, and exceeding it can also produce a permanent SPF error.

For example, this record references two provider hostnames:

v=spf1 include:_spf.old-provider.example include:_spf.missing.example ~all

If those names do not exist, or if they resolve successfully but return no SPF record, they count as 2 void lookups, reaching the limit.

Void lookups often happen when legacy directives are left in an SPF record even after the corresponding domain or provider is decomissioned or no longer exists.

MX address lookup limit

The mx mechanism lets an SPF record authorize the IP addresses of the MX hosts of a domain. When evaluating this mechanism, there’s a separate independent limit of 10 address lookups for the MX hosts.

Looking at an example will make this clearer. Consider the following SPF record:

v=spf1 mx ~all

To evaluate it, the receiver first looks up the MX records of the domain. For example, the query could return two MX hosts:

example.com MX 10 mx1.example.com
example.com MX 20 mx2.example.com

Then, it goes through each of the MX hosts to resolve the IP addresses of these hosts. Whether it runs A or AAAA queries depends on whether the client is connecting via IPv4 or IPv6.

mx1.example.com A 198.51.100.10
mx1.example.com A 198.51.100.15
mx2.example.com A 198.51.100.20

In this case, the SPF verifier performs 2 address lookups: one for mx1.example.com and one for mx2.example.com.

Each A or AAAA query counts toward the MX address lookup limit. A domain that has too many MX hosts can easily exceed this limit.

Note that these address lookups do not count toward the overall DNS lookup count: an mx mechanism could exceed its own MX lookup limit even when the overall lookup count is less than 10.

How to fix lookup limit issues

The strategies for fixing issues with SPF lookup limits depend on whether the issue is produced by infrastructure you control or by external providers.

Most of the time, you’ll deal with the 10 lookup limit. There are a few ways you can reduce the number of queries:

Remove unused services

Review your SPF record for unused external services. Often, removing just an include directive may be enough to stay below the limit.

Move email providers to subdomains

Many email service providers let you use a custom Envelope From/Return-Path identity on a subdomain.

This lets you use the main domain as the From sender, while having a dedicated SPF record for the specific email provider on a subdomain, letting you remove include directives from the main SPF record.

Send from subdomains

If using a custom Envelope From is not possible, you can also consider using a subdomain as the sender (From) for email flows that you consider less important.

For example, you could send your newsletter from no-reply@newsletter.example.com instead of no-reply@example.com, removing burden from the main SPF record.

Move less important directives toward the end of the record

Sometimes, email providers force you into adding their include directive in your main SPF record even though they use a subdomain as the Envelope From (which removes the need for changing your main SPF record).

In these cases, consider moving that specific include directive at the end of the record, before the ~all or -all directive. Since SPF records are evaluated left to right, this reduces the likelihood of hitting the limit during normal evaluation, which would stop at the previous directives for legitimate email.

Remove unnecessary a/mx directives

Many times, hosting providers add directives such as a or mx to your SPF record by default, even if they’re not required. Remove them if that’s the case, they’ll save you a DNS lookup each.

Keep your limits monitored

Using a tool such as DMARCwise lets you keep your SPF record and its resolution chain constantly monitored. Seeing which part of your SPF chain is responsible for most of the lookups is the first step to fix the issue.

Don’t split the SPF record into multiple records

SPF does not merge multiple records: publishing more than one SPF record is invalid and leads to the SPF record being ignored.