An email migration involves more than moving user mailboxes. Websites, devices, aliases, shared addresses and business applications can depend on the old configuration. Treating the move as a single MX change leaves those dependencies to be discovered by users after the cutover. A practical plan makes the intended mail path and rollback visible before anyone changes DNS.
Inventory every mail source and destination
List user addresses, aliases, shared addresses and systems that send automated email. Include invoicing, contact forms, monitoring and devices. Assign an owner to each item and identify which ones are essential on the first day. An application nobody owns is still a migration dependency.
Record the current state
Save the existing MX, SPF, DKIM and DMARC records together with receiving destinations and application sending settings. Note where each record is managed and who may edit it. Keep previous values in the change record so rollback does not depend on memory or an old screenshot in a chat.
Agree on a cutover window and define the conditions that would trigger rollback. “If users complain” is not a clear condition. A specific failed test or an unavailable destination is easier for the team to act on consistently.
Prepare before publishing
Create the required addresses, permissions and destinations before directing incoming traffic to the new route. If an incoming gateway is involved, verify its forwarding destination and the receiving system’s expected traffic. Avoid configuring a destination that resolves back to the same gateway.
Update the sending inventory separately. An application using the previous submission route may continue working for a while or fail independently of incoming delivery. Neither outcome proves that the migration is complete.
Test representative workflows
- External incoming mail to a normal user.
- Incoming mail to a shared or aliased address.
- Normal outgoing mail to an external recipient.
- One message from each important business application.
- A reply that follows the expected address and permissions.
- A held-message workflow if quarantine is in scope.
Use clear subjects and record the sender, recipient, timestamp and expected outcome. Check delivery records as well as the user’s view. Authentication results should be reviewed on actual messages, not inferred solely from published DNS records.
Monitor the transition and close deliberately
DNS caches can present different views during a change. Keep the previous route available for the agreed transition period where the migration design allows it. Watch for mail reaching an unexpected destination, application failures and addresses missing from the inventory.
Before closure, confirm which old settings and access paths may be retired. Remove them through a documented change after the team has verified the new workflows. Record unresolved exceptions instead of silently leaving the old system as a permanent fallback.
Use the free DNS tools to compare public records and the sender inventory guide to identify application dependencies.