An email-provider migration can leave two legitimate sending systems active at once. The safest SPF plan starts with the messages and identities that will exist during that overlap. Adding the new provider is only one step; removing the old one too early or retaining it indefinitely creates different problems.
Inventory the migration boundary
List employee mail, application notifications, billing, automated replies and devices that relay through the old platform. For each flow, capture the actual envelope domain and outbound route. The visible From address is not necessarily the SPF identity. Use the email identity chain to keep those fields separate.
Ask the new provider for the current instructions for your tenant and configuration. Some services use their own envelope domain unless a custom return path is configured. Adding an include to your root domain does not automatically alter that identity. Do not invent provider values or reuse another tenant's setup.
Design the overlap policy
Preserve one applicable SPF record at each evaluated owner name. Do not publish the old and new policies as separate competing SPF records. RFC 7208 §3.2 and RFC 7208 §4.5 define the selection constraint.
Build a candidate containing the still-required authorisations. Evaluate the combined dependency tree because two individually acceptable configurations can produce a problematic combined path. Test the actual envelope domains and IP families in use. Avoid merely counting top-level includes or assuming a provider name in DNS proves the right configuration.
Record the intended final nonmatching result and ensure it has not changed accidentally. A migration is not a reason to grant universal authorisation. Keep DKIM setup and DMARC alignment verification in the plan as distinct workstreams.
Rehearse the cutover
This illustrative migration has staff mail moving on Monday while an invoicing application remains on the old relay until Friday. Removing the old authorisation on Monday would ignore the application schedule. Conversely, leaving it forever because invoices once used it would avoid the decommissioning decision. The plan needs a separate owner and exit criterion for that flow.
Before production, preserve the old DNS value, the proposed overlap value and the recovery decision. Review previous TTLs and expected caching behaviour without promising that all receivers change simultaneously. Test the new path with ordinary messages and important automated variants, not only a provider's internal verification screen.
Check the receiver's evidence
Collect a received sample from each relevant route and inspect the trusted receiver's authentication result, evaluated envelope identity and visible From domain. RFC 8601 explains the trust boundary for Authentication-Results; a header inserted outside that boundary is not independent proof.
A raw SPF pass does not establish DMARC alignment. RFC 9989 section 4.4 relates authenticated identities to the Author Domain. Confirm the new route's aligned authentication rather than treating a successful DNS lookup as completion. Delivery can still depend on other receiver policies.
Remove the old authority deliberately
Use application-owner confirmation, sending logs and representative observation to decide when the old route is no longer needed. Consider queued retries and unusual scheduled jobs. There is no single waiting period that proves every organisation has stopped using a provider.
Prepare and approve a second policy change that removes only the retired scope. Repeat positive and negative evaluations and verify the remaining flows. Keep a rollback plan that accounts for whether the old service still exists; a saved DNS record cannot restore a cancelled sending account.
Close the migration when the inventory, DNS, received-message tests and ownership records agree. Keep the retirement evidence so the next administrator knows why the old provider was removed rather than re-adding it in response to an unrelated failure.
DNS background: RFC 1035 section 3.2.1 defines resource-record TTL; RFC 2308 §5 covers negative caching; RFC 8767 §4 updates TTL semantics and permits stale use when authoritative refresh fails. These describe DNS behaviour, not a universal completion time for a change.
Record the next decision
Track staff and invoices as separate rows: owner, current route, actual envelope domain, overlap requirement, new-route evidence and retirement condition. Staff cutover does not authorize removing the invoice dependency. If the old account is cancelled, mark routing rollback unavailable even if an old DNS value is saved. This is a proposed acceptance record, not an executed migration.