MX is only the inbound switch
Changing MX records moves the public inbound route, but a mailbox migration can also affect outbound authentication, shared-mailbox permissions, aliases, applications, scanners, CRMs, forwarding rules and user identities. Treating the project as a DNS change misses most of the failure surface.
Find non-human senders before cutover
Printers, monitoring systems and old applications frequently use SMTP credentials or relay rules tied to the current provider. These dependencies are easy to overlook because they may send only during an incident or monthly process. Inventory them before changing authentication or relay endpoints.
Preserve authentication overlap
Where the providers allow it, prepare target-side DKIM and other authentication records before the final cutover. Simulate SPF additions before publishing them, especially if the existing record already has many recursive includes. Migration day is the worst time to discover that adding one more provider caused SPF evaluation to exceed its budget.
Define post-cutover acceptance tests
Test external inbound mail, employee outbound mail, transactional applications, aliases, shared addresses, forwarding and representative calendar or collaboration flows. Keep a rollback plan until those workflows have been verified from outside the organization, not only from an administrator console.
Verify the evidence
Use the Email Infrastructure Digital Twin to establish the public control plane, then inspect message-level evidence with Email Header Forensics.