Evidence and research

What Happens When a Flattened SPF List Goes Stale?

By EmailmetryReviewed 2 min read

A flattened record can have a low lookup count and still authorise the wrong addresses. A provider-IP change shows why additions and removals both matter.

A provider adds a new sending address

Consider a fictional provider whose SPF record initially authorises 192.0.2.10. A domain uses an include for that provider, while a manually flattened copy lists the address directly.

The provider then moves its sending service to 192.0.2.20. After DNS caches pick up the change, the ordinary include leads to the new address. The saved flattened copy still lists the old one.

Record or senderBefore the moveAfter the move
Provider recordv=spf1 ip4:192.0.2.10 -allv=spf1 ip4:192.0.2.20 -all
Manually copied recordv=spf1 ip4:192.0.2.10 -allUnchanged
Message from 192.0.2.20 against the copied recordNot authorisedStill not authorised

The copied record has no lookup-producing terms, yet it no longer describes the intended sender. Low lookup counts and current authorisation are separate requirements. These reserved addresses illustrate the mechanism; they are not a provider's real records.

A copied address list can fall behind

The provider changes its sending address from 192.0.2.10 to 192.0.2.20 while a manually copied SPF list still authorises only the old address.
Reserved example addresses illustrate a provider change. An ordinary include follows the updated provider record after caches refresh. A static flattened copy must be updated to add the new address and remove the old one.
Read the diagram as text
  1. Initially the provider and the manually copied record both authorise 192.0.2.10.
  2. The provider moves to 192.0.2.20 and removes 192.0.2.10.
  3. The static copy remains unchanged: it still authorises the old address and omits the new one.
  4. Automatic flattening needs to follow both additions and removals.

Removed addresses matter too

The stale copy continues authorising 192.0.2.10 after the provider removes it. Checking only whether the new address was added misses that half of the change.

An automatic flattener needs to follow additions and removals, validate the result and publish the updated list. DNS caching still means receivers may temporarily use an older answer. The DNS propagation checker helps inspect which TXT answers locations currently see, but does not inspect the flattener's internal refresh jobs.

A provider update is different from retiring a service

If the business stops using this provider altogether, continuing to follow its records would keep authorising it. Automatic refresh cannot infer that the contract ended or the application was switched off.

The business needs to remove the service from its intended senders. The email service discovery worksheet helps record who owns that decision.

Provider guidance still matters

Microsoft advises against flattening its Microsoft 365 SPF include because the sending addresses change frequently. Automatic updates do not turn that advice into an endorsement. Microsoft's SPF guidance

The flattening guide covers supported rules, updates and validation. A different problem, where the provider adds nested references without changing your record, is explained in why SPF can fail without a local DNS change.

Sources and further reading

Sources reviewed 12 September 2026.