Is SPF Flattening Safe? The Trade-offs, Honestly

Is SPF flattening safe? The honest answer is that it depends entirely on whose records you are flattening. Replacing an include: mechanism with the raw IP addresses behind it is a legitimate, standards-compliant way to fix the SPF 10-lookup limit. But it trades a live DNS lookup for a static list that you now own and have to maintain.

For a vendor with stable, published IP ranges, that trade is reasonable. For a dynamic cloud sender that rotates its addresses without telling you, it is a slow-motion outage. This guide gives the verdict first, then the mechanics, the steps to flatten without breaking mail, and what to check when authentication fails anyway. The lookup limit and error behaviour below are quoted from RFC 7208 and Microsoft's own SPF guidance, both checked in August 2026.

The short answer: flatten stable vendors, never dynamic ones#

SPF flattening is safe when two things are true at once: the sender publishes a stable, documented set of sending IP addresses, and you commit to reviewing that list on a schedule. Miss either half and you are storing up a failure.

It is unsafe for any sender whose IPs are dynamic. Microsoft 365 and Google Workspace both change their sending addresses regularly and expect you to reference their include:, not pin their IPs. Flatten one of those and the copy in your record goes stale the moment they rotate — silently, because nothing errors until a receiver actually checks.

The only reason to flatten at all is the lookup ceiling. RFC 7208 section 4.6.4 requires an evaluator to stop after 10 DNS-querying terms and return a permerror. Flattening removes lookups by swapping a lookup-costing include: for zero-cost ip4: and ip6: entries.

Before you start: confirm you actually have the problem#

Flattening adds maintenance work, so only do it if you are genuinely over the limit. A record sitting at nine lookups never needs flattening; a record at eleven does. Run your domain through any SPF checker that counts DNS lookups before you change anything.

Then sort your senders. List every include: in your record and mark which vendor publishes a fixed IP range and which is a cloud platform that rotates. That single split decides everything that follows — including whether you use ip4: instead of include: at all.

• Watch the void-lookup limit too. RFC 7208 says an evaluator SHOULD stop after two void lookups — queries that return no records — so a dead or misspelled include: can fail you before you ever reach ten.
• Get the vendor's IP documentation in writing. If a sender does not publish its ranges, that alone is a reason not to flatten it.
• Remember flattening is reversible. You can always put the include: back — which is exactly what you do the moment a vendor's IPs start moving.

How to flatten an SPF record safely#

1. 1

   Count your current lookups

   Use a checker that reports DNS lookups, not just syntax. Confirm you exceed 10 and note which include: entries contribute the most, including nested ones you cannot see in the raw record.

2. 2

   Flatten only the stable includes

   For a vendor with documented, fixed ranges, look up its published IPs and replace its include: with the matching ip4: and ip6: entries. Record the vendor and the date in a change log.

3. 3

   Leave every dynamic sender as an include:

   Microsoft 365, Google Workspace, and most large relays stay as include:. Their SPF is theirs to maintain; pinning their IPs is the mistake that breaks mail weeks later.

4. 4

   Watch the record length

   A single DNS TXT string is capped at 255 characters; longer records split into multiple quoted strings that resolvers rejoin. Flattened records grow fast, so keep the total size in view.

5. 5

   Publish, then verify

   After the TTL clears, re-run the checker. Confirm the lookup count is under 10 and that validation returns pass — not permerror — for a real test message.

6. 6

   Put the review on a calendar

   Microsoft recommends re-checking flattened entries at least quarterly. Diarise it, and re-verify after any vendor announcement about its sending infrastructure.

What to flatten and what to leave alone#

Flattening is a decision you make per sender, not a switch you flip on the whole record. The same SPF record can correctly pin a fixed-IP appliance and correctly leave Microsoft 365 as a live lookup. The table below is the whole verdict, sender by sender.

A per-sender call, not a one-time cleanup#

Get that split right and flattening buys you real headroom under the limit. Get it wrong on a single dynamic sender and you have introduced a failure that only surfaces when their IPs move — often weeks later, when nobody is looking at DNS.

What to do when SPF still fails after flattening#

If authentication fails after you flatten, the cause is almost always a stale list or a record that outgrew what resolvers accept. Work through these in order.

• permerror right after flattening a cloud sender: you pinned IPs that have since rotated. Put that vendor's include: back and re-test.
• Still a permerror for too many lookups: you flattened the wrong entries. Flatten the stable ones, and move a bulk or third-party sender to a subdomain instead of pinning it.
• Bounces citing too many lookups or exceeded the hop count: that is Microsoft's non-delivery wording for a permerror. Re-count your lookups, including nested includes.
• A void-lookup failure: a lookup returned no records, or a flattened include: you deleted is still referenced elsewhere. RFC 7208 caps void lookups at two.
• Record rejected as too long: split it into multiple quoted TXT strings, or move a sender to its own subdomain.

Where AI Emaily fits, and where it doesn't#

SPF flattening is a DNS job, and AI Emaily is a mail client — it does not edit your DNS, flatten your record, or watch a vendor's IP ranges for you. If automated flattening is what you need, an SPF-management or flattening service is the honest recommendation, and the steps above are the fix if you would rather keep it manual.

There is one point worth knowing if you are already near the lookup ceiling: connecting AI Emaily does not add anything to your SPF record. It sends through your existing Gmail, Outlook, or IMAP mailbox rather than as a separate relay, so outbound mail keeps using the same authorized servers your SPF already lists — no new include:, no extra lookup, no change to your record. We build AI Emaily; what it does is triage, filing, and drafting on the receiving side, not sending-domain authentication.