It is a limit written into the standard that almost nobody knows about until they hit it: evaluating an SPF record may make at most ten DNS queries. Not ten entries in the record — ten queries, which is a different and worse thing.
Once past the ceiling, the record does not stop existing. It returns a permanent error, and from then on your company's mail is judged as though SPF were absent. No warning, no message: just delivery getting worse.
What consumes a lookup
These cost one query each, and they are the ones that accumulate over time:
include:— the entry added every time you authorise an external service;aandmx— convenient and expensive;ptr— not to be used anyway, for other reasons;redirect=— counts like the rest;exists:— rare, but counts.
ip4: and ip6: cost nothing, because they are addresses already written down and no question has to be asked.
The part that catches everybody out: an include: is not worth one. It is worth one plus everything that record includes in turn. A large mail provider's record often contains two or three more, and the count is recursive.
Why companies get there without noticing
Nobody designs an SPF record over the limit. You arrive there by accumulation, one service at a time, over years:
- the business email provider;
- the ERP, sending order confirmations;
- the newsletter platform;
- the e-invoicing service;
- the CRM sending quotes;
- the shop;
- the website form;
- and finally the one added last week, which tipped the count.
None of the additions was wrong. The sum is wrong, which is why the problem shows up months after the last change anybody remembers making.
How to count
By hand it is possible but tedious: read your record, resolve every include:, and count the nested queries, recursively.
In practice you use one of the public SPF validators, which do exactly that and tell you how many lookups you are at. The number to watch is not how many include: entries you wrote, but the computed total.
Rule of thumb: if the total is nine, you are already in trouble. The next service somebody adds will be added without asking anyone's permission.
The four ways back under
1. Remove what no longer sends. This is the first step and it is often enough. Nearly every record carries authorisations for platforms the company has not used in years. If a service has sent no mail in twelve months, it is not a sender.
2. Replace include: with ip4: where it makes sense. If a service sends from fixed, published addresses, you can list those directly: zero lookups. With a service that changes infrastructure often, though, it is a fragile choice — the address changes, you do not know, and mail stops passing. Fine for a server of your own, less so for a large cloud provider.
3. Drop a and mx if they are not needed. These are the entries people add out of habit. mx authorises your inbound mail servers to send: if they do not send, it is a lookup given away.
4. Move senders onto a subdomain. This is the structural fix, and the right one when the first three are not enough. Newsletters go out from a dedicated subdomain with its own SPF record and its own independent count; invoicing from another. The main domain becomes light again and the reputation of each stream is separated, which is an advantage regardless of the limit.
What is not a solution is splitting the record in two: one domain may have exactly one SPF record, and having two is an error that invalidates both.
The detail that keeps mail alive during the work
While you are fixing this, keep the end of the record on ~all rather than -all. The first says "treat what is not on the list with suspicion"; the second says "reject it". With a count you are still unsure of, the difference between them is a quiet afternoon of work or a day of blocked email.
You move to -all at the end, when the count is under the limit and the DMARC reports confirm that no legitimate sender is left outside. Which is why this work is done alongside DMARC in observation mode rather than on its own: without the reports you are guessing which senders really exist.
One last thing, about a record you inherit
If you have just taken over somebody else's domain, look at the SPF count before anything else. It is one of the most reliable indicators of how that mail has been treated over the years: a record at the limit tells a story of additions without a single review, and next to it you usually find DKIM keys for decommissioned services and a DMARC record that is not there.