SPF's 10 DNS lookup limit and how to stay under it

What is an SPF record?

SPF (Sender Policy Framework, RFC 7208) lets a domain owner publish which servers may send email using the domain in the envelope sender, also called the return path or MAIL FROM. Receiving servers look up the record and compare it with the IP address of the connecting server.

The record is a DNS TXT record on the domain itself. It starts with v=spf1 and lists mechanisms that are checked from left to right. The first one that matches decides the result. A typical record looks like this:

example.com. TXT "v=spf1 ip4:192.0.2.10 include:_spf.mailprovider.example mx -all"

Only one SPF record may exist per name. If a receiver finds two TXT records that start with v=spf1, the result is a permerror. Each string inside a TXT record can hold at most 255 characters. A longer record is split into several quoted strings in the same TXT record, and receivers join them without adding spaces.

Which SPF mechanisms count toward the limit?

RFC 7208 section 4.6.4 limits the number of terms that cause DNS queries to 10 per SPF evaluation. These terms count:

• include: each include counts as one, and every lookup inside the included record counts as well.
• a: one lookup for the A or AAAA record of the named host.
• mx: one lookup for the MX records. The address lookups for each MX host are bounded separately, at 10 per mx mechanism.
• ptr: counts as one, and it is not recommended at all.
• exists: one lookup.
• redirect: the redirect modifier counts as one, and the target record's lookups count as well.

The mechanisms ip4, ip6 and all do not cause DNS queries, so they do not count. The exp modifier is only evaluated after a fail and does not count toward the limit either.

How do nested includes add up?

The limit applies to the whole evaluation, not to your own record. If you include a provider whose record has three includes of its own, that one include costs you four lookups. Large providers often use several nested levels, so a record with only four or five includes can still pass 10.

Providers can also change their records at any time. A record that was at 9 lookups last month can be at 11 today without any change on your side. Check the full count regularly, not only when you edit the record.

What is the void lookup limit?

The same section of RFC 7208 adds a second limit. A void lookup is a DNS query that returns no answer, either NXDOMAIN or an empty response. Receivers should allow at most 2 void lookups per evaluation and return a permerror after that.

Void lookups usually come from includes or a mechanisms that point to names that no longer exist, such as an old provider or a removed host. Removing stale terms fixes both the void count and the overall lookup count.

What happens when SPF returns permerror?

A permerror means the record could not be evaluated correctly. Too many lookups, too many void lookups, two SPF records, or a syntax error all lead to it. Two records or a syntax error break SPF for every sender. With too many lookups, evaluation stops when the limit is reached, so every sender matched after that point gets a permerror, and some receivers reject the whole record. Do not count on early matches to save you.

For DMARC, only an SPF pass with an aligned domain counts. A permerror is not a pass, so DMARC then depends entirely on DKIM. Messages with a valid, aligned DKIM signature still pass DMARC. Messages without one fail, and with p=quarantine or p=reject they can be sent to spam or rejected.

How do I reduce the number of SPF lookups?

• Remove senders you no longer use. Old newsletter tools, CRM systems and test services are common leftovers.
• Replace a and mx with ip4 or ip6 where you control the addresses and they rarely change, such as your own mail server.
• Move senders to subdomains. A marketing platform can send from news.example.com with its own SPF record, which has its own limit of 10.
• Rely on DKIM for senders that sign with your domain. If a service signs with an aligned DKIM key, DMARC can pass without that service being in your SPF record.
• Never use ptr. RFC 7208 says it should not be used. It is slow, unreliable, and costs lookups.

Some services offer SPF flattening, which replaces includes with the provider's current IP addresses. This lowers the count, but providers change their addresses without notice. A flattened record that is not updated automatically will start failing for legitimate mail. If you flatten, make sure something keeps the record in sync and alerts you when it changes.

DMARC Vision's free SPF record checker runs in your browser and flags lookup-limit risk in a record before you publish it.

Should I use ~all or -all?

The all mechanism at the end decides what happens to servers that are not listed. -all gives a fail, ~all a softfail and ?all a neutral result, while +all lets every server on the internet pass. None of them affects the lookup count.

-all is the goal. It is the clearest statement a domain can make: only the listed servers send for it. ~all is a reasonable step while you are still finding all your senders, but it leaves each receiver to decide for itself, which is why the Email Security Check marks it as needing attention. Never use +all or ?all.

Move to -all once your DMARC reports show that every legitimate sender passes, and preferably once those senders also sign with DKIM aligned with your domain. Some receivers reject on an SPF fail before they look at DKIM, and forwarded mail is the case most likely to be affected.