SPF Flattening: Fix DNS Lookups Safely

SPF flattening fixes one limit and creates one chore

A single new include can push a working SPF record over the 10-lookup limit. The failure is ugly: SPF returns permerror, DMARC loses one of its two ways to pass, and good mail starts looking suspicious.

SPF flattening means replacing include mechanisms with the actual IP ranges behind them. For example, instead of publishing include:send.example, you publish the ip4 and ip6 values that provider currently uses. This can reduce DNS lookups because ip4, ip6, and all do not trigger SPF DNS lookups.

The risk is drift. Providers change sending IPs. If you flatten once and forget it, you can remove a valid sender next month without knowing. That is why flattening is a maintenance job, not a one-time cleanup.

The rule that forces the issue

RFC 7208 gives SPF a hard ceiling: only 10 DNS-querying mechanisms and modifiers may be used while checking one SPF record.

The SPF mechanisms that count are include, a, mx, ptr, and exists. The redirect modifier counts too. Nested includes count. If an include points to another record with more includes, those lookups are part of your total. If the total goes over 10, the receiver must return permerror. RFC 7208 also recommends a separate limit of two void lookups, where DNS returns no answer or NXDOMAIN.

That matters because DMARC can pass through SPF only when SPF passes and the SPF domain aligns with the visible From domain. If SPF hits permerror, you are left depending on DKIM alignment. If DKIM is missing, broken, or signed by the wrong domain, DMARC fails. Gmail says all senders need SPF or DKIM, and bulk senders need SPF, DKIM, and DMARC. Microsoft also tells custom-domain senders to configure SPF, DKIM, and DMARC, with alignment as the point of DMARC.

Use this order before flattening

Flattening should be the last fix you reach for. Most bloated SPF records have old vendors, duplicate includes, or senders that belong on a subdomain.

• List every service that sends mail for the domain: Google Workspace, Microsoft 365, help desk, CRM, billing, marketing, product mail, and any cold email tool.
• Remove vendors you no longer use. Old includes still spend lookup budget and still authorize outside systems.
• Use one SPF TXT record only. Multiple SPF records at the same host cause SPF errors.
• Move special senders to subdomains when it fits. For example, use news.example.com for marketing mail or mail.example.com for product mail, each with its own SPF, DKIM, and DMARC setup.
• Avoid a, mx, and ptr unless you have a clear reason. ptr is called out in RFC 7208 as a mechanism to avoid.
• Prefer provider includes when you are under the limit. The provider then owns IP changes.

If you still need flattening after that cleanup, automate it. Pull the provider SPF tree on a regular schedule, rebuild the IP list, publish the new TXT value, and alert when the source changes. Do not hand-copy IPs into DNS and leave them there.

How to flatten without breaking authorization

Safe flattening is boring. It starts with proof, then a small DNS change, then monitoring.

• Count the real SPF lookups first, including nested includes and redirects. Do this from DNS, not from a spreadsheet.
• Flatten only the include that causes the lookup pressure. Leave stable provider includes alone when they fit.
• Keep the record under DNS size limits. Very long TXT records can create their own delivery problems.
• End with ~all while you are still proving the setup. Move to -all only when every legitimate sender is covered and DMARC reports look clean.
• Keep DKIM healthy for every sender. The DKIM selector points receivers to the public key in DNS. The DKIM signing domain is the part that should align with your From domain when possible.
• Publish DMARC at _dmarc. Start with p=none and a rua address for aggregate reports. Tighten to quarantine or reject after you know legitimate mail is passing.
• Check MX records and blocklists if mail still lands in spam after authentication passes. SPF flattening fixes authorization, not reputation, list quality, content, or user complaints.

A free InboxRadar domain check can show whether your SPF record is over the lookup limit and whether DKIM, DMARC, MX, and blocklist checks are clean. Use it as a quick read before touching DNS.

When SPF flattening is a bad idea

Flattening is risky when the sender changes IPs often or does not publish a stable source record.

It is also a poor fix for a domain that mixes every mail stream at the root. If your newsletter vendor, billing system, support desk, and sales tool all share the same root SPF record, you will keep fighting the limit. Split by subdomain where the mail stream and brand risk allow it.

Do not flatten to hide a messy sender list. Receivers care about more than SPF pass. Gmail and Outlook use authentication, domain reputation, IP reputation, complaints, content signals, user behavior, and policy. Broken SPF can send you to spam or rejection fast, but passing SPF alone does not buy inbox placement.

For the exact rules, use the primary sources: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, plus the current Google sender guidelines and Microsoft email authentication guidance.