SPF flattening can go stale: the lookup fix that silently shifts vendor IP maintenance onto you

What the standard or provider is actually evaluating

SPF includes delegate part of the authorization decision to another domain. Flattening resolves that dependency into static ip4 or ip6 mechanisms, which do not consume the same SPF DNS-lookup budget but can become stale when the provider changes addresses.

Flattening converts a provider-controlled include tree into a snapshot of IP mechanisms that you now own. That can reduce DNS-query depth, but it also transfers change detection from the provider to you. A vendor can add or remove sending ranges without changing your domain, and a flattened record will not learn about that change automatically. The operational question is therefore not “does the flattened record pass today?” but “who is responsible for keeping this copy synchronized?” Microsoft’s own SPF guidance is a good illustration: dynamic service ranges are precisely the kind of dependency that should not be copied casually into a static customer record. Treat flattening as an exception with an owner and refresh process, not as the default cure for every lookup warning.

The shortcut that breaks the diagnosis

A flattened record often looks faster and more deterministic, so it is easy to mistake it for a permanent repair. The hidden cost is that a vendor can change its include data without any change to your DNS, while your copied IP list remains frozen.

A stale flattened record fails in two directions. If a provider adds a new legitimate outbound range, mail from that range can fail SPF because your static snapshot never included it. If the provider retires a range and it later changes ownership, your domain may continue authorizing infrastructure you no longer intend to trust. The second risk is easy to overlook because deliverability checkers usually focus on whether legitimate messages pass, not on over-broad authorization. Before flattening, ask whether the original problem is actually stale includes, duplicated providers, or poor stream separation. Fixing inventory can remove the lookup pressure without creating a permanent synchronization job.

Build a control case before editing production

Before flattening, save the provider’s published include tree and compare it with the candidate literal ranges. Afterward, schedule a diff against the authoritative vendor source and send test messages that exercise each provider route.

If you inherit a flattened policy, reconstruct its source. Compare every published ip4 or ip6 range with the provider’s current supported SPF include and official range documentation where available. Send test messages from each service and inspect the envelope sender plus Authentication-Results. Then set a reminder appropriate to the provider’s change rate and record the date of the last reconciliation. A diff is more useful than a screenshot: it tells you exactly which networks appeared, disappeared, or changed. If nobody can explain where a block came from, treat that as a configuration debt item rather than blindly preserving it because mail happens to pass today.

Fix the state that the evidence names

Prefer removing unused vendors and separating genuinely different envelope domains before flattening. If flattening is still necessary, assign an owner, refresh interval, alert path, and documented source of truth for every imported address range.

The safer repair is usually to restore supported provider includes after reducing unnecessary mechanisms elsewhere, or to move distinct streams onto subdomains with their own narrowly scoped SPF policies. When flattening is unavoidable for a stable, documented sender, keep the generated record under version control and automate comparison against the authoritative source. Never let a third-party flattening tool become an unreviewed source of truth. After any change, test every legitimate stream and confirm that the total policy still stays within SPF evaluation limits. The goal is a policy whose authorization can be explained, not merely one that fits inside a checker’s current lookup counter.

An operator-sized scenario

Microsoft explicitly cautions against flattening its dynamic Microsoft 365 SPF include because infrastructure changes can invalidate a static copy. The same operational principle applies to any cloud sender whose IP ranges are not contractually stable.

If a team chooses flattening anyway, the flattened record should be treated like generated code. Store the source include targets, the resolver output used to create the IP list, the generation timestamp, and a diff from the prior version. Review removals as carefully as additions: a disappeared provider network may indicate a legitimate infrastructure change, but it may also reflect a temporary DNS problem during generation. Do not publish an automated diff blindly. A staging step that compares expected sending streams against the proposed list can catch both missing and unexpectedly broad authorization. For providers that explicitly warn against flattening dynamic service ranges, follow their supported include mechanism instead. This approach keeps the trade-off visible: flattening can buy lookup headroom, but only by creating an ongoing synchronization responsibility that a small team must actually be willing to own.

Fields that make the decision auditable

Track when the flattened set was generated, which provider document or DNS records supplied it, how many ranges changed on each refresh, and which messages prove the new set works after publication.

Do not turn this edge case into a universal rule

Never paste a flattened record from a random checker and treat it as vendor documentation. A checker can expand today’s DNS; it cannot promise what the provider will send from next quarter.

Field checklist

• Capture the raw evidence for SPF flattening stale provider IPs risk before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using spf-rfc, microsoft-spf rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for SPF flattening can go stale: the lookup fix that silently shifts vendor IP maintenance onto you and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.