SPF Too Many DNS Lookups: What Dynamic SPF Is and When You Need It

This is one of the few deliverability problems with an exact, checkable cause and a definite answer. It is also one of the most under-diagnosed, because the failure is completely silent: your DNS record looks right, your mail leaves normally, and receivers quietly stop trusting it.

The rule

When a receiving mail server evaluates your SPF record, it is allowed to perform a maximum of ten DNS lookups. If evaluation requires more, the check returns permerror, and the practical effect at most receivers is that SPF fails.

Two details do most of the damage:

It is not ten entries, it is ten lookups. The mechanisms that cost a lookup are include, a, mx, ptr, exists, and the redirect modifier. The ones that cost nothing are ip4 and ip6, because an IP address needs no resolving.

Lookups nest. This is the part that catches people. When you write include:_spf.example.com, that record is fetched, and if it contains its own include mechanisms, those are fetched too, and all of them count against your ten. A single include from a large provider can consume three or four lookups on its own. Four innocent-looking includes can be over the limit.

You did not do anything wrong. Your provider expanded their record and yours broke.

How to know if this is you

Do not count by eye. Use any SPF validator that reports a lookup count, and look for the words "too many DNS lookups", "permerror", or a count above ten.

The other place it shows up is in DMARC aggregate reports, where you will see SPF results coming back as permerror rather than pass or fail. If you are not reading those reports, this is a good argument for starting: it is exactly the class of problem that is invisible from the sending side and obvious from the receiving side.

Symptoms that should make you check:

• Mail from one particular sender started landing in spam and nothing about that sender changed.
• You recently added a new tool that sends on your behalf.
• Your DMARC reports show SPF neither passing nor failing but erroring.
• You have four or more include mechanisms in your record.

The four fixes, in the order to try them

1. Delete what you no longer use

Genuinely the most common fix and the only one with no downside.

SPF records accumulate. A trial of a marketing tool three years ago, a helpdesk you migrated off, an invoicing system nobody uses. Each one is still costing lookups and still authorising a third party to send as your domain, which is a small security issue as well as a budget issue.

Go through every mechanism in your record and answer "does this system still send mail as us?" Remove anything where the answer is no. Teams doing this for the first time frequently drop back under the limit at this step and can stop reading.

2. Replace includes with ip4 ranges, carefully

ip4 mechanisms cost zero lookups. If a sender publishes a stable, documented set of sending IPs, you can list them directly instead of including their record.

The caveat is the whole story here. This is only safe when the sender documents the ranges as stable and tells you when they change. Most large providers explicitly do not: they change sending infrastructure without notice, which is precisely why they give you an include that they maintain on your behalf. Hard-coding their IPs converts their maintenance job into yours, silently.

Reasonable candidates: your own mail servers, a fixed relay you control, a sender with a published static range and a change notification. Poor candidates: any large cloud email provider.

3. Dynamic SPF, also called SPF flattening

This is what people are searching for when they search "dynamic SPF record", and it is worth explaining properly because the static and dynamic versions of the same idea have very different risk profiles.

Flattening means resolving all your include mechanisms down to the raw IP addresses they ultimately authorise, then publishing those as ip4 mechanisms. Since ip4 costs no lookups, the resulting record fits comfortably under the limit.

Static flattening is doing that once, by hand, and pasting the result into DNS. Do not do this. The IPs behind a large provider's include change regularly, and your frozen snapshot will authorise addresses that no longer send your mail while failing to authorise the ones that do. It breaks weeks later, gradually, in a way nobody connects to a DNS edit made last month.

Dynamic SPF is a service that hosts the flattened record for you, re-resolves the upstream includes on a schedule, and updates the published record when they change. Your domain gets one include pointing at the service; the service keeps the contents current.

That maintenance is the entire product. If you are considering a dynamic SPF provider, the questions worth asking are about exactly that:

The trade-off is real: you have introduced a third party into the authentication path for all of your mail. For a domain with genuinely many senders it is the right call. For a domain with four senders, two of which are unused, fix number one is better.

4. Move senders to subdomains

Each domain gets its own ten lookups. A sender moved to mail.yourdomain.com or notify.yourdomain.com takes its includes with it and stops competing for the parent domain's budget.

This is the structurally cleanest answer and the one that requires the most coordination, because the sending system has to be reconfigured to use the subdomain. It pairs well with the general advice to keep cold outreach on a separate domain anyway, and it has a side benefit: reputation becomes separable, so a marketing blast cannot damage the authentication story of your transactional mail.

While you are in there: one SPF record only

A related failure worth checking at the same time. A domain must publish exactly one SPF record. Two v=spf1 TXT records on the same domain is a permerror regardless of how many lookups each one uses.

This happens when two people each add a record for their own tool rather than editing the existing one. Merge them into a single record with all the mechanisms.

Also: ?all and a missing all mechanism both mean "no opinion", which authenticates nothing. End with ~all (softfail) while you are still verifying your setup, and -all (hard fail) once you are confident every legitimate sender is listed.

DMARC without SPF is not a catastrophe

A common panic when SPF breaks is that DMARC must now be failing too. Usually it is not, and understanding why takes the urgency down to the correct level.

DMARC passes if either SPF or DKIM passes with proper alignment. It is an OR, not an AND. So a domain with a broken SPF record and correctly configured, aligned DKIM will still produce DMARC passes, and your mail will still be broadly trusted.

This is one of several good reasons DKIM deserves as much attention as SPF, and it is why the full authentication setup treats all three records as one job rather than three optional ones.

None of which means leave SPF broken. Relying on a single passing mechanism removes your margin: the day something disturbs DKIM, you have nothing. Fix the lookups.

The order of operations

1. Check your record with a validator and get the actual lookup count.
2. Remove senders you no longer use. Re-check.
3. Confirm there is exactly one SPF record on the domain.
4. Replace includes with ip4 only where the sender documents stable ranges.
5. If still over ten, choose between dynamic SPF and moving senders to subdomains, based on how many senders you genuinely have.
6. Verify DKIM is signing and aligned, so DMARC has a second leg to stand on.
7. Read your DMARC aggregate reports for a fortnight afterwards to confirm the fix took.

Step seven is the one that gets skipped, and it is the only one that proves anything. Everything before it is a change you believe worked.

Where to go next

• SPF, DKIM and DMARC: the 20-minute setup for the full authentication picture.
• DMARC for cold email for policy choice and reading the reports.
• Why emails go to spam for what else to check when authentication is already correct.