Migration
Change email hosting without downtime: migrate mail without losing messages
To change email hosting without losing mail, build and test the destination before changing MX, copy historical messages first, keep the old service available while cached DNS answers expire, and run a final synchronization for messages that reached the old provider during the transition.
Inventory mailboxes, aliases, forwards, groups, and senders
Do not migrate only visible inboxes. Document shared addresses, catch-all behaviour, autoresponders, distribution groups, application SMTP accounts, forwarding rules, quotas, and any systems that send mail for the domain.
Create and test the destination before MX changes
Provision every destination mailbox and alias first. Authenticate through webmail or a client, prepare any required SPF, DKIM and DMARC changes, and verify controlled sending and receiving before public mail routing changes.
Copy historical mail before the cutover
Run an initial IMAP or provider-supported migration while the old service is still authoritative for incoming mail. This moves the bulk of existing messages before the routing change and shortens the final synchronization window.
Change MX only after the receiving path works
Update the domain’s MX records when the destination is ready, and preserve any unrelated DNS records the domain still needs. DNS resolvers can keep cached answers until their TTL expires, so some senders may continue delivering to the old provider during the transition. MX preference chooses among published mail exchangers; it is not a timed cutover switch.
Synchronize mail that arrived during the transition
Keep the old mail service reachable after the MX change and run another synchronization to collect messages that arrived there while caches were still using the previous route. Compare representative folders and message counts before declaring the move complete.
Update clients and retire the old service last
Give users exact incoming and outgoing settings, monitor both providers for bounces and authentication failures, and verify application senders separately. Cancel the old service only after mail flow has settled and no messages remain stranded there.