Changing mail providers changes receiving hostnames, certificate ownership and sometimes fallback behavior. MTA-STS can expose an unsafe migration order: DNS begins advertising a new provider while some senders still enforce a policy that permits only the old one.
Inventory both sides of the migration
References: RFC 8461 §4, RFC 8461 §8.2.
Record the old and proposed MX names, priorities, addresses, STARTTLS behavior and certificate identities. Obtain the new provider's current routing and MTA-STS guidance, then verify the exact names in your own planned DNS change. A provider's branding or a guessed wildcard is not an authoritative hostname inventory.
Review whether policy HTTPS hosting or discovery DNS is also tied to the departing provider. Moving receiving mail while accidentally cancelling the policy host creates a second failure. Keep policy publication, certificate renewal and reporting destinations explicitly owned through the move.
Publish a compatibility policy first
References: RFC 8461 §3.2, RFC 8461 §4, RFC 8461 §8.1.
Prepare a policy that permits the necessary old and new receiving hosts without changing mail routing yet. Test that both groups match and that the new group passes SMTP certificate and STARTTLS checks. Publish the HTTPS body before changing the discovery id.
Allow a transition interval based on the previously published policy max_age, DNS TTL and observed refresh behavior. Lowering max_age at the moment of migration does not shorten a policy fetched earlier. Where possible, retain a functioning old route that satisfies old cached policies while the new policy is distributed. Do not promise that changing id instantly updates all senders.
Rehearse the three policy states
References: RFC 8461 §4.1.
Use two synthetic names, mx.old.example and mx.new.example. Policy A permits only old; policy B permits both; policy C permits only new. The expected compatibility matrix is A: old true, new false; B: both true; C: old false, new true. The supplied bounded offline fixture was rerun for this review and records these name comparisons, not delivery.
This matrix proves only the named-policy membership relation. A realistic rehearsal also needs DNS answers, valid certificates, STARTTLS, recipient acceptance and actual test-message delivery. Those live migration tests were not performed for this article. Preserve their future outputs separately rather than treating the local matrix as a successful provider cutover.
Move routing and retire deliberately
References: RFC 8461 §5.1, RFC 8461 §8.1.
After the compatibility stage, switch MX routing through the approved change process. Observe delivery at both providers, sender errors, queues and TLS reports. Confirm business recipients and recovery routes, including low-volume addresses that a single inbox test would miss. Keep old service available for the planned overlap.
Only then narrow the policy to the intended new set and announce another id. Preserve the previous body and consider how rollback would work with senders caching the new-only policy. Re-adding the old MX in DNS alone may not restore delivery for that cohort. Close the migration when route, policy and operational evidence support retirement, not merely when the DNS editor shows the new provider.
Retained historical evidence and remaining scope
The following describes preserved 7 November 2026 observations, not a network experiment rerun for this review. Newly executed offline checks are recorded separately.
The extended rehearsal links the membership matrix to publication and lifetime state. A1 permits old only and can remain valid until logical time 1086700 when its latest modelled fetch is considered. B2 permits both providers; its body is fetched through the lab HTTPS endpoint after the DNS id changes. C3 permits only new. The modelled B2 and C3 expiry times, 1004200 and 1004500, occur before the older A1 bound because A1 used a longer lifetime. Thus promoting C3 or switching DNS at the B2 publication time alone is not evidence that all old-only senders are ready. The trace demonstrates actual local DNS/HTTPS plus explicit policy-state arithmetic. It does not test provider recipient acceptance, public DNS caches, mail delivery or business-address coverage; these remain the cutover gate.