SPF: too many DNS lookups — and the bigger number underneath it

Most people arrive at this subject through an error message: too many DNS lookups, or a checker returning PermError. The fix is well documented and this guide covers it. But the error is a symptom of something the fix does not address, and almost nobody counts it: the number of IP addresses your domain currently authorizes to send mail as you. On one real record we assessed, that number was 1,086,996.

The error, and what actually triggers it

SPF is evaluated by the receiving mail server, at delivery time, by walking your record and resolving whatever it points at. RFC 7208 caps that walk at ten DNS-querying mechanisms. Exceed it and the evaluation does not fail politely part-way through — it returns PermError, and a receiver treating PermError as a failure stops honouring your record at all. Legitimate mail from senders that were listed correctly starts landing in spam, and it happens to every sender at once.

The reason it surprises people is that the count is not the number of entries you typed. It is the number of lookups the receiver performs, which includes everything your includes include. A record naming seven mailing platforms can easily require fifteen.

Scroll the table sideways →

There is a second, quieter cap: at most two “void” lookups — queries that return nothing. An include pointing at a domain that no longer publishes a record is not inert. It spends budget and, past two, it breaks the record.

The fix, and the tradeoff in the popular version of it

• —Remove senders you no longer use. In most records that is the entire fix, and it is the only one with no downside.
• —Delete a and mx mechanisms unless those hosts genuinely send mail. They are the most common stale entries, and a stale a record can point at infrastructure someone else now controls.
• —Delete ptr outright. RFC 7208 deprecates it.
• —Replace a vendor's broad include with the narrower record they publish for it, where they publish one.
• —Consolidate subdomain senders onto a subdomain with its own record, so the organisational domain stops carrying every sender.

The remaining option is flattening: resolving the chain yourself and publishing the resulting ip4: blocks directly, which cost nothing against the limit. It works, and it moves the problem rather than removing it. Your providers change their ranges without telling you, and a flattened record is correct on the day it is generated and progressively wrong afterwards. If you flatten, it needs to be regenerated on a schedule by something that will still be running in a year.

The number nobody counts

Every checker will tell you whether you are over ten lookups. We have not found one that answers the question a security owner would ask instead: how many distinct IP addresses can currently send mail that passes SPF for our domain? The arithmetic is not hard. Resolve the whole chain, collect every ip4: and ip6: block, and add up what the prefixes mean.

Scroll the table sideways →

A real record, counted

The following is a real chain from an assessment of a mid-sized B2B SaaS company, anonymised — the domain is not named, and everything below was read from public DNS that any visitor can query. No system was accessed and nothing was scanned.

• —The chain nested eight levels deep: the organisational record pointed at spf1, which pointed at spf2, and so on to spf8 — eight of the ten permitted lookups spent on structure alone.
• —Those eight records held 77 explicit ip4: blocks, totalling 1,086,996 IPv4 addresses.
• —The six largest blocks were not the company's own infrastructure. They were shared ranges belonging to two hyperscale mail providers, a public cloud, and a transactional email service — a /14, a /15 and four /16s.
• —The chain terminated in ~all, a softfail, not -all.
• —DMARC was published at p=quarantine with relaxed alignment on both SPF and DKIM.

Read those last two lines together with the first three. Mail sent from anywhere inside a million-address envelope passes SPF for the domain. Relaxed alignment lets it align. A quarantine policy asks receivers to set it aside rather than reject it — and plenty of receivers deliver quarantined mail to a folder the recipient still reads. Nothing in that sequence requires a vulnerability, an exploit or a credential. It requires an SMTP client and a position inside a shared range.

That last part is the step people wave away, so it is worth being precise about how cheap it is. The BreakSPF research presented at NDSS assembled a pool of 87,430 usable addresses across five shared-infrastructure providers at a cost of under one cent per address, and used it to confirm 23,916 domains that could be spoofed as a direct consequence of over-broad SPF — 23 of them in the Tranco top 1,000. The same work found that 51.7% of domains in the Tranco top million authorize more than 65,536 addresses through their SPF chain. The slides are public. A million-address record is not an outlier. It is the median outcome of a decade of adding senders and never removing any.

Count your own, in about five minutes

You need dig and a calculator. Nothing here touches a system you do not own, and nothing here sends mail. If you would rather not do the arithmetic, the same walk runs as code in the free SPF DNS lookup checker — it returns both numbers and prints every record it read, so you can check the working.

• —1 · dig +short TXT yourdomain.com — find the line beginning v=spf1. That is your record.
• —2 · Write down every include:, a, mx, exists: and redirect= in it. That is your first-level lookup cost.
• —3 · For each include, run the same query against that hostname. Repeat until nothing new appears. Keep a running lookup count as you go; if it passes ten, you have found your PermError.
• —4 · Collect every ip4: and ip6: block from every record in the chain, discarding duplicates.
• —5 · Convert each IPv4 prefix to its address count — 2 to the power of (32 minus the prefix length) — and sum them. IPv6 blocks are effectively uncountable and worth listing rather than totalling.
• —6 · Note the final qualifier: ~all or -all. Then dig +short TXT _dmarc.yourdomain.com and note p= and whether aspf/adkim are r or s.

Now look up who owns the largest blocks — an RDAP query against the relevant registry will tell you. The useful version of the finding is never “we authorize a million addresses”. It is “we authorize a million addresses, 590,000 of which belong to shared provider ranges we do not control, and our policy asks receivers to quarantine rather than reject”. One of those sentences can be acted on.

Where this sits against your other findings

Practitioners genuinely disagree about how seriously to weigh this, and the disagreement is reasonable, because severity-scored tooling has no opinion on it at all. There is no CVE and no CVSS score for a record that trusts too much, so it does not appear on the report that drives most remediation queues. Ranking it needs the three questions that rank anything: can something outside your boundary reach it, what does the attacker actually need, and what is behind it.

• —Reachability: any tenant inside the authorized shared ranges, from the public internet, with no access to you.
• —Exploitability: no exploit code, no credentials, no user interaction — a mail client and a pretext.
• —Business relevance: this is the domain your customers and your finance contacts already trust. Invoice fraud and credential phishing both run on exactly that trust.
• —Cost to fix: DNS changes and a staged policy move. No engineering sprint, no code change, no downtime if it is sequenced properly.

On those four, an over-broad SPF chain frequently outranks findings scored 9.8 — which is the argument made at length, with a worked reordering, in how to prioritize security findings when everything is labelled critical.

The sequence for actually reducing it, in the order that avoids breaking your own mail: inventory who legitimately sends as you, remove everyone else, narrow what remains, then tighten policy in stages — DMARC p=none with aggregate reports arriving first, so you can see what you are about to block, then quarantine, then reject, and only then consider moving ~all to -all. Reversing that order is how companies break payroll notifications.

What the number does not tell you

It is not evidence that anyone has spoofed you. It is a measure of what is permitted, not of what has happened — and the two get conflated in vendor material more often than they should. Only your DMARC aggregate reports show what is actually being sent in your name, which is a good reason to publish a rua address even at p=none.

Nor is a large count automatically an incident. A domain that authorizes a single well-run provider’s range has a big number and a defensible one. The finding is about ranges you do not control and senders nobody can name, not about arithmetic for its own sake.

And it is one of three signals. SPF says where mail may originate; DKIM proves it was not altered; DMARC ties either of them to the domain a human reads. A tight SPF record alongside unsigned mail and no DMARC policy is a locked window in an open house. If the reason you are reading this is that a customer asked how you authenticate mail, the companion piece on answering a security questionnaire without a security team covers how to evidence that answer rather than assert it.