A cloud mailbox migration can finish successfully while invoices, alerts and scanned documents stop arriving. Those workflows may send through devices, applications or third-party providers outside the mailbox tenant. Build the migration inventory around business mail paths, not only the list of user accounts being moved.
Map the systems the tenant list misses
Ask each business and infrastructure team which systems send messages. Include customer communications, billing, identity workflows, incident alerts, printers, website forms, scheduled reports and SaaS campaigns. Record purpose, owner, criticality, sending method, network dependency and evidence of the last end-to-end test.
For each path, distinguish visible From, envelope sender, DKIM signing domain, destination scope and bounce handling. Document whether the service talks directly to an external provider, an on-premises relay or a tenant endpoint. Microsoft explicitly documents several application-mail methods with different prerequisites and restrictions. Direct Send is limited to recipients in the organization; SMTP relay and authenticated submission have different setup requirements. Microsoft guidance. Verify the current supported method for the actual provider rather than copying another platform's settings.
Connect transport to authentication
Changing the mailbox platform does not automatically update an application's sender configuration or DNS. Establish who signs each stream, which envelope identity SPF evaluates and how an aligned identifier relates to the visible From domain. RFC 9989. Inventory DKIM selectors and third-party dependencies before removing old records.
Also identify IP-based relay restrictions, certificates, firewall rules, connector dependencies and credential references without exporting the secrets. Record which team owns each dependency. An MX change principally changes inbound routing; it is not a complete migration plan for outbound application mail.
Make recipient scope a migration gate
Suppose customer receipts use a SaaS signing route, a printer uses an internal relay, and an incident application submits through the old platform. The receipt route may remain outside mailbox cutover but still depends on its DNS and provider account. The printer and incident application require their own destination, network and submission checks; migrating employee accounts does not resolve those dependencies.
If the incident application must notify an external on-call address, Microsoft Direct Send is not an appropriate route for that required external delivery. Verify a supported method with the actual account and network prerequisites instead. This hypothetical scope decision does not configure a tenant or test provider eligibility. Preserve a hold until the selected route has authorized end-to-end evidence.
Plan coexistence deliberately
For each service, specify the old path, new path, cutover owner, test cases, failure signals and rollback action. Keep only the parallel authorizations required for the approved coexistence period. Duplicate sends are a separate risk: migrating an application job and leaving its old scheduler active can send the same notification twice even when both messages authenticate.
Exercise internal and external destinations where the business requires them. Test bounce processing, retry behavior and monitoring alerts as well as receipt of one successful message. Retain receiver evidence for signature and alignment results. An SMTP acceptance response alone does not prove the destination mailbox displayed the message or that the application processed a failure correctly.
Set an exit condition for the old platform
Do not decommission the old relay because all user mailboxes moved. Close every dependency row with observed success, an approved exception or an explicit retirement decision. Include scheduled flows that have not run during the cutover window. Export the evidence needed for future troubleshooting before access to the old platform expires.
When retiring permissions, use exact record changes and service configuration changes under normal approval. Remove old credentials and authorizations only after the corresponding service is migrated or retired. State remaining unknowns in the migration decision so incomplete evidence is not mistaken for completion.