A provider adding sending IP addresses usually does not require you to edit a normal SPF include. Receivers consult the provider's DNS policy, subject to caching. A flattened copy of those addresses needs separate updating. Changes to referenced policies can still affect SPF evaluation and require investigation if sending starts to fail.
A provider can add sending servers without requiring a customer DNS edit. Whether an update reaches your SPF policy automatically depends on how that policy refers to the provider.
An include follows the provider's policy
A normal include: delegates part of the SPF check to another domain's policy. The SPF specification defines that evaluation.
If the provider changes the addresses in its policy while keeping the documented include hostname, your reference can stay the same. Receivers get the updated information through DNS as cached answers expire. That is native SPF behaviour.
This does not mean an include can never cause a problem. A provider can change nested dependencies or publish a broken policy. Our article on SPF changing without a local DNS edit covers that separate issue.
A copied address list needs maintenance
Flattening replaces references with IP addresses. That removes the live reference for those entries: a new address at the provider does not insert itself into the copy.
Microsoft's SPF guidance advises against flattening Microsoft 365's include because its sending addresses change. A copied policy needs an appropriate update mechanism; it cannot rely on the native reference it replaced.
If a different provider supports an appropriate flattened configuration, the update mechanism becomes part of that design. Check its actual requirements before deciding how it will be maintained.
Business changes are a different trigger
Adding a sender, retiring a platform or moving to a different MAIL FROM configuration can require a customer DNS change. That is a change in what the business uses, rather than routine maintenance caused by the provider adding servers.
If a change causes a failure, somebody has to find the affected dependency, correct the problem and verify the sender. There can also be useful work in checking a planned change before it disrupts sending. Both prevention and recovery matter, even though ordinary provider updates need no manual edit. Neither implies that every update creates a ticket.
Sources and further reading
Sources reviewed 8 September 2026. Our editorial standards.