SPF Flattening: When It Helps, When It Hurts, and How to Do It Safely
SPF has one rule that quietly breaks more domains than any other: a receiver will follow at most ten DNS lookups when evaluating your record, and at the eleventh it gives up and returns permerror for every message. Flattening is the usual fix. It works, and it creates a maintenance problem that most people discover six months later. Here is how to decide whether to do it and how to do it without the surprise.
What counts as a lookup
include:, redirect=, a, mx, ptr and exists: each cost one, and includes are recursive: every include nested inside a vendor's record counts against your budget too. ip4: and ip6: cost nothing. That is the whole basis of flattening — replace the mechanisms that cost lookups with the addresses they resolve to, and the count drops to zero. The lookup counter shows the tree and exactly where your budget goes.
Try these before flattening
Delete stale includes. Every audit finds a vendor that stopped being used two years ago. Free, zero risk. Drop ptr. Deprecated, costs a lookup, and some receivers penalise it. Move heavy senders to a subdomain. A marketing platform that sends from news.yourdomain can have its own SPF record there, and its includes stop counting against the root. Check whether a vendor offers a lighter include. Some publish per-region or per-product includes that are one lookup instead of three.
Most records over the limit get back under it with those four steps alone. Flatten only what is left.
What flattening changes
A flattened record lists the IP networks that each vendor's include resolved to on the day you ran it. The lookup cost is gone. What is also gone is the vendor's ability to update those networks for you. When they bring up a new sending pool — and the large ones do this regularly — your record does not know, mail from that pool fails SPF, and nothing on your side warns you. DMARC reports will show it as a rising SPF failure rate from a known source, if anyone is reading them.
The two problems and how to contain them
Staleness. Assign an owner and a schedule. Monthly re-resolution is the floor for anything involving Google, Microsoft, Amazon SES or a major ESP. If nobody will own it, do not flatten those vendors; keep them as includes and flatten the small static ones instead.
Length. DNS TXT strings are capped at 255 characters and the record is split across several; that part is routine. The real limit is that the whole DNS response should fit in a UDP packet, which in practice means keeping the record under about 1,500 characters so old resolvers do not choke on TCP fallback. A full flatten of Microsoft 365 alone is 1,450 characters. The flattener reports the length and does the string split.
The hybrid that actually holds up
Keep the primary mail provider as a single include — Google and Microsoft each cost one lookup and both rotate ranges. Flatten the long tail: the helpdesk, the billing system, the form tool, the monitoring service that sends four alerts a week. Those ranges are small and rarely change. A twelve-lookup record typically becomes four or five with almost no ongoing maintenance. Document which block of addresses came from which vendor and when, in a note next to the DNS record, so the next person can maintain it.
Whatever you publish, run it through the SPF checker for syntax and the lookup counter for the count before touching the live record, and keep the previous record in a note so you can revert in one paste.
A note on cold email fleets
Secondary sending domains almost never have this problem: one provider, one include, one lookup. The domain that goes over is the primary business domain that has accumulated a decade of SaaS vendors. Fix it there, and keep the sending domains simple.
Sources
- RFC 7208 §4.6.4 — DNS lookup limits — IETF
- RFC 7208 §3.3 — Multiple strings in a single DNS record — IETF
Tools for this
SPF lookup counterCount DNS lookups against the limit of ten.SPF flattenerCollapse includes into IP ranges.SPF checkerValidate a record and see who it authorises.Frequently asked questions
Is SPF flattening safe?
Safe on the day, risky over time. Flattened ranges go stale when vendors change IPs. It is safe if someone re-resolves the record on a schedule; otherwise keep the big vendors as includes.
How do I know if I am over the limit?
Run the domain through the SPF lookup counter. It expands every include and shows the total against ten. A record over the limit returns permerror, which most receivers treat as a fail.
Can a flattened record be too long?
Yes. Keep it under roughly 1,500 characters. Longer records risk exceeding the UDP response size. The flattener reports the length and warns.
Should I flatten Google or Microsoft?
Usually not. Both are one lookup and both change ranges. Keep their include and flatten smaller vendors around them.
What about SPF macros?
Macros let you build a dynamic record that resolves per sender, which avoids the limit entirely. They require infrastructure to serve the responses and are overkill for most domains; some DMARC services offer it as a hosted product.