What is SPF flattening and should I use it?

SPF (Sender Policy Framework, RFC 7208) lets a domain publish the list of servers allowed to send mail on its behalf. Most records describe those senders by name — include:_spf.google.com, include:spf.protection.outlook.com, mx — and each name must be resolved with a DNS query when a receiver evaluates the record. RFC 7208 caps the number of DNS-querying mechanisms at 10. The mechanisms that count are include, a, mx, ptr, exists, and redirect, and includes count recursively, so a few third-party providers can quietly push you past the limit.

The problem flattening solves

When a record exceeds 10 lookups, conformant receivers return a permerror and treat SPF as failed. That breaks SPF authentication and DMARC alignment, which can send legitimate mail to spam. This is the "SPF too many DNS lookups" error you may have seen in a checker or a DMARC report. (See how many SPF lookups are allowed and how to fix an SPF permerror.)

What flattening actually does

SPF flattening replaces every include, a, and mx mechanism with the literal ip4: and ip6: addresses it resolves to. The key insight is that ip4 and ip6 mechanisms cost zero DNS lookups — the receiver reads the address directly and never queries DNS. So a record that needed 12 lookups can be reduced to 0. The SPF flattening tool walks your full SPF graph, follows every include and redirect, resolves the A/AAAA/MX records they point to, deduplicates the result, and builds a single v=spf1 ip4:… ip6:… <qualifier>all record while preserving your original all-qualifier (such as -all or ~all).

The honest trade-off: should you use it?

Flattening is not free, and for most domains it is the wrong first move. A flattened record is a static snapshot of IP addresses that your providers control and rotate at will — and they do not announce the changes. The moment a provider adds a new sending IP, your record stops authorizing it and legitimate mail starts failing SPF; when a provider retires an IP, your record keeps trusting an address that may later belong to someone else. A flattened record therefore degrades silently: nothing breaks loudly, deliverability just slowly worsens. If you flatten, you must re-flatten on a schedule — ideally automatically — or accept that slow degradation. A few other mechanisms also cannot be flattened at all: ptr depends on reverse DNS at validation time (and is deprecated anyway), and exists relies on runtime macro expansion, so both are dropped with a warning.

What to do instead, and when to flatten

Reach for cleanup first. Remove include: entries for services you no longer use, consolidate overlapping providers, and move high-volume senders (newsletters, ticketing, transactional mail) onto dedicated sending subdomains that each carry their own SPF record. These changes cut lookups without creating maintenance debt and are almost always the better fix. Flatten only when you have genuinely exhausted cleanup and are still hitting permerror — and then treat the flattened record as something you own and must keep current. You can verify any record with the SPF checker, build a fresh one with the SPF generator, or read the background on the SPF learn page.