SPF flattening is the fix people reach for when their Sender Policy Framework record stops working, and it is usually the second answer rather than the first.
The problem it solves is real: every SPF record has a hard ceiling of ten DNS lookups, and crossing it does not weaken the record, it fails the whole thing. But flattening trades one problem for another, and it is worth understanding both before you rewrite anything in your domain settings.
The limit that actually breaks things
An SPF record lists which servers are allowed to send email using your domain. Most of that list is not addresses, it is pointers at other companies: your mail provider, your marketing platform, your ticketing system, your payroll software.
Following each pointer costs the receiving mail server a DNS lookup, and RFC 7208 caps those at ten per evaluation. The eleventh does not get ignored. The receiving system abandons the check and returns a permanent error, which most receivers treat much the same as publishing no SPF record at all.
Nothing warns you. The record still reads correctly where you published it. Mail that depended on it starts being refused or filed as spam, and the first sign is usually a customer saying they never received something.
Which parts of the record cost a lookup
Not every mechanism counts. This is the part most people get wrong when they try to count by eye.
| Mechanism | Costs a lookup | Notes |
|---|---|---|
include: | Yes | The most common cause of an over-limit record |
a | Yes | Resolves the domain's address records |
mx | Yes | Plus further resolution of each mail server name |
ptr | Yes | Deprecated, remove it if you find it |
exists: | Yes | Rare outside advanced setups |
redirect= | Yes | Counts, and replaces the rest of the record |
ip4: / ip6: | No | Plain addresses, free |
all | No | The catch-all at the end |
The count is also recursive. An include: pointing at a provider whose own record contains three more includes spends four of your ten, not one. This is why a record that looks like five entries can quietly be sitting at twelve.
Try hardening first
Before flattening anything, take out what should not be there. Two things are usually hiding in a record that has gone over.
Void lookups. These are entries pointing at a name that resolves to nothing: a provider you left, a domain that was retired, a hostname somebody mistyped years ago. Each one still spends a lookup, and only two are allowed before the third turns the whole record into a permanent error on its own, entirely separately from the ten-lookup ceiling.
Unused and overly broad senders. Entries still authorising tools you stopped sending from, along with the broad ones that authorise a whole shared platform to send as you. Every one is a wasted lookup and a standing permission somebody else could use.
Plenty of records come back inside the limit on deletions alone. That result is better than a flattened one, because a record built from include: still follows its sources automatically. If hardening gets you under ten, stop there.
We treat these as two named jobs for exactly this reason, and most records need one rather than both. There is more on where the line sits in Managed SPF.
What flattening actually does
Flattening resolves the pointers down to the addresses behind them and publishes the result as one record.
Before, at eleven lookups:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com
include:mail.zendesk.com include:_spf.salesforce.com
include:servers.mcsv.net ~all
After, at zero:
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14
ip4:192.161.144.0/20 ip4:198.2.128.0/18 ... -all
The lookup count stops being the constraint, because there is nothing left to look up. That is the whole benefit, and it is a genuine one for a record that cannot be cut down any further.
Note the ending as well. Once every genuine sender is accounted for, the catch-all moves from soft fail to hard fail, so anything not on the list is refused rather than merely doubted. There is more on that choice in SPF softfail explained.
The trade-off nobody puts in the sales page
A flattened record is a snapshot, not a live pointer.
When you publish include:_spf.google.com, you are asking the receiving server to fetch whatever Google says is current, every time. When you flatten it, you have written down what Google said on Tuesday. The companies you send through renumber without telling anyone, and when they do, your record is wrong in one of two ways:
- Under-authorised. A provider moves onto addresses your record does not list, and their mail starts failing your SPF check. Same symptom as the problem you were trying to fix.
- Over-authorised. You keep addresses that no longer belong to that provider. In the worst case they have been reassigned to somebody else, and you are authorising a stranger to send as you.
The second is the quieter risk and the one worth taking seriously. A flattened record left alone for a year is not a solved problem, it is a permission list that has stopped being true.
Anyone who tells you a flattened record is set and forget is selling you a problem for later. It needs re-checking against its sources and republishing when they move, which is work that has to belong to somebody.
You also trade lookups for length
Flattening swaps one limit for another, so the result has to be checked against DNS size limits too.
- A single TXT character-string is capped at 255 characters. Longer records get split into multiple strings, which receivers concatenate.
- Keep the whole DNS response under 512 bytes where you can. Above it, resolvers fall back to TCP or EDNS, and while that normally works, it is one more thing that can behave badly on a badly configured network in the middle.
A large sending estate flattened naively can produce a record that is inside the lookup limit and awkward on length. Both need to pass, not just the one you were fixing.
How to decide
Work down this list in order:
- Count your lookups. If you are under ten with no dead entries, do nothing. A working record does not need improving.
- Remove the dead pointers. Entries resolving to nothing cost you lookups and cost you the record entirely at the third one.
- Remove what you no longer send from. Old platforms, trial tools, the ticketing system you replaced.
- Narrow what you can. Where a provider offers a dedicated sending domain rather than a shared platform-wide entry, move onto it.
- Still over ten? Now flatten, and put a re-check on a schedule at the same time.
Steps two through four are hardening. If they get you under the limit, you keep a record that maintains itself, which is worth more than a shorter one.
Doing it without breaking mail
The real risk in this work is not the edit, it is removing a sender that is still in use.
That is why the DMARC reports come first. The daily aggregate reports every major email provider sends back name every source that has actually sent as your domain, with volumes. An entry can be shown to be unused before it is removed, rather than assumed to be. Anything that cannot be placed stays in the record until it is accounted for.
The sequence that works:
- Turn on DMARC reporting and collect at least a few weeks of data.
- Reconcile every sender in the reports against every entry in the record.
- Remove the dead and the unused, then re-count.
- Flatten only what is left over, if anything is.
- Re-check the flattened record against its sources on a schedule, and republish when a provider moves.
- Tighten the catch-all to hard fail once nothing genuine is failing.
Step five is the one that gets skipped, and it is the one that decides whether flattening was a fix or a delayed outage.
Check your own count first
Our SPF tree viewer expands your record pointer by pointer and counts it against the ten-lookup limit, which tells you straight away whether flattening is even in question. It reads public domain records only, so nothing is changed and nothing is published.
If you are at four lookups, this article is not your problem. If you are at eleven, start with what you can delete before you start rewriting.
Where we come in
Managed SPF covers both jobs as one piece of work: hardening the record first, flattening it only if hardening is not enough, then keeping a flattened record in step with the providers behind it for as long as we run your records. It sits as an optional extra alongside managed email authentication, because most of the value comes from the DMARC reports that make the edits safe in the first place.
If you would rather do it yourself, the tool above is free and the sequence is written out above. What makes it fiddly is not the edit, it is tracing which pointers have gone dead, knowing which entries are safe to drop, and keeping a snapshot in step with companies that renumber without notice.
