SPF flattening, and the maintenance debt nobody mentions

SPF flattening replaces include: mechanisms with the literal ip4/ip6 ranges they currently resolve to. Because ip4 and ip6 cost zero DNS lookups, this reliably fixes a PermError caused by the 10-lookup limit. The cost is that you have converted a dynamic reference into a static snapshot: when your email provider changes its sending IPs — which it will, without notifying you — your flattened record is silently wrong and mail starts failing SPF.

Updated July 14, 2026 · SPF

Why it works

The 10-lookup limit counts DNS-querying terms. include: queries; ip4: does not — the receiver simply compares the connecting IP against the range in the record. So resolving your includes ahead of time and inlining the results converts an expensive record into a free one.

Before  (7 lookups — over budget once you add a third sender)
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

After   (0 lookups)
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 … ~all

Why it is not free

The entire purpose of include:_spf.google.com is that Google can change what is behind it. Google adds a sending range, updates the record, and every domain that includes it is correct the next time a receiver evaluates it. That indirection is the feature.

Flattening deletes the feature. You now own a hardcoded copy of somebody else's infrastructure. When they renumber:

Be honest about what a "flattening service" is selling. The recurring products in this space are not selling flattening — flattening is a few lines of code. They are selling someone to re-flatten it for you when the upstream changes. That is a real service and it is the actual value. Our flatten endpoint is a diagnostic: it tells you the truth at the moment you ask. It is not a managed SPF service and we will not pretend otherwise.

Try it

We resolve the includes and return a record with the lookup count driven to zero.

What to do instead, if you can

  1. Delete dead includes. Audit which ESPs you actually still send from. This alone fixes a surprising share of over-budget records, costs nothing, and cannot break.
  2. Split by subdomain. Each subdomain gets its own SPF record and its own budget of 10. Marketing on mail.example.com, transactional on send.example.com. No maintenance, no snapshot to go stale.
  3. Lean on DKIM. DMARC needs one of SPF or DKIM to pass and align. Aligned DKIM survives forwarding, which SPF does not.
  4. If you must flatten, monitor it. Something has to re-check the upstream record on a schedule and tell you when it moves. Otherwise you have installed a time bomb with no timer display.

Frequently asked

What is SPF flattening?

Replacing include: mechanisms in an SPF record with the actual ip4 and ip6 ranges those includes resolve to. Since ip4 and ip6 mechanisms require no DNS query, the record's lookup count drops, which fixes a PermError caused by exceeding the 10-lookup limit.

Is SPF flattening safe?

It is technically correct but operationally fragile. A flattened record is a point-in-time snapshot of your provider's IP ranges. When the provider adds or renumbers sending IPs — which they do without notice, because the whole point of include: is that they can — your record no longer authorizes them, and mail from those IPs fails SPF. Nothing alerts you; it simply starts failing.

What is the alternative to SPF flattening?

Sending different mail streams from different subdomains. Marketing from mail.example.com, transactional from send.example.com — each subdomain publishes its own SPF record with its own budget of 10 lookups. This is the structurally correct fix, it needs no maintenance, and it is what large senders do. Removing unused ESP includes is also free and is often enough on its own.

Does SPF have a 512-byte or 255-character limit?

A single TXT character-string is capped at 255 characters, and a flattened record will usually exceed that — it must be split into multiple quoted strings within one TXT record, which resolvers concatenate. Separately, keeping the whole DNS response under 512 bytes avoids TCP fallback. A heavily flattened record can bump into both, which is another reason flattening is not free.

Related

Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.