Flatten a record
How it works
Full recursive expansion
Every include and redirect is followed to the bottom of the tree. a and mx mechanisms are resolved to their A and AAAA addresses.
Networks are merged
Duplicate ranges are dropped and the result is sorted so you can read it. exists: mechanisms are kept as they are, since they cannot be flattened.
Length is checked
TXT strings max out at 255 characters, so the record is split for you, and you are warned if the whole thing is large enough to cause UDP problems.
You decide what to keep
The expansion tree shows which vendor contributed how much. Flatten the small static ones and keep the include for the giants.
When flattening is the right answer
SPF allows ten DNS-querying mechanisms per evaluation. Go over and the receiver returns permerror, which most treat as a fail for every message from the domain. The honest fixes, in order, are: delete includes for services that no longer send, drop ptr, move bulk senders onto their own subdomain with a separate record, and only then flatten.
Flattening replaces an include with the IP ranges it currently resolves to. The lookup cost disappears because ip4: and ip6: cost nothing. What you lose is the vendor's ability to update those ranges for you. When they add a sending pool, your record does not know, and mail from the new pool fails SPF with no warning on your side.
Where flattened records go wrong
They silently rot. Google, Microsoft, Amazon SES and the big ESPs change ranges regularly. A flattened record for any of them needs re-resolving on a schedule — monthly is the floor. If nobody owns that task, keep the include and flatten something else.
They get too long. A single TXT string is limited to 255 characters; a record can hold several strings, but the whole DNS response has to fit in a UDP packet for older resolvers, which in practice means keep the record under about 1,500 characters. A full flatten of Microsoft 365 plus Google plus two ESPs can blow past that. The tool tells you the length and splits the strings for you.
They hide the vendor. Six months later nobody remembers which block of ip4: ranges belongs to which service, so cleanup stops happening. Keep a comment in your DNS provider, or in a document next to it, mapping each block to its source and the date it was resolved.
A workable middle path
Most fleets land on a hybrid. The primary mail provider stays as an include because it is one lookup and it changes ranges. The long tail — a helpdesk, a billing system, a form tool that sends four emails a week — gets flattened because those ranges are small and rarely move. That usually brings a twelve-lookup record down to four or five with no ongoing maintenance burden worth worrying about.
Whatever you publish, count it again with the lookup counter and validate the syntax with the SPF checker before changing the live record. Then set a calendar reminder for the re-resolve.
Frequently asked questions
Is flattening safe?
It is safe on the day you do it, provided you re-check the record. The risk is time: vendors change IP ranges and a flattened record does not follow them. Treat it as a maintained artefact with an owner and a schedule, not a one-off fix.
Why does the flattened record still have lookups?
exists: mechanisms cannot be flattened because they depend on the sender's address, so they are kept as-is and each costs one lookup. Everything else is resolved to networks.
Should I flatten Google or Microsoft?
Usually not. Both are a single lookup and both rotate ranges. Keep their include and flatten the smaller vendors around them.
What does the split into strings mean?
DNS TXT records are made of strings no longer than 255 characters each. A long SPF record is published as several quoted strings inside one record; receivers concatenate them. Most DNS panels do the split automatically when you paste the full string.
Will the qualifier at the end be preserved?
Yes. The flattened record ends with the same -all, ~all or ?all your current record uses. If it ends in +all the tool keeps it, but you should not.
Can I flatten a subdomain's record?
Yes — enter the full hostname. Subdomain records are a good way to isolate a high-lookup vendor from your primary domain in the first place.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.