MX Migration: How to Move Without Losing Email Data

14 hours ago

11 min read

An MX migration moves your email routing and mailbox data from one provider to another. Done in the right order, inventory, provision, lower TTL, sync, cut over, delta sync, verify authentication, you can complete the switch with zero message loss and minimal downtime, even for large mailbox estates. The sequence matters more than the individual steps. Skip one, and you risk losing messages that arrived during the propagation window or breaking delivery with misconfigured authentication records.

What Does MX Migration Actually Mean?

An MX migration, in the context of email, is the process of updating your DNS Mail Exchanger records so that incoming messages route to a new mail server, and moving your existing mailbox data to that new server so nothing is left behind.

This guide covers email only: updating MX records in DNS, copying mailbox data between servers, and preserving forwarders, aliases, and authentication records through the switch.

The two core operations are separate but dependent. Changing your MX record redirects new incoming mail to the new server. Synchronizing your mailboxes copies existing messages from the old server to the new one. Neither step alone completes a migration. You need both, in the right order, with a delta sync at the end to catch messages that arrive during the propagation gap.

Getting this right matters at any scale. A single missed step, forgetting a forwarder, skipping the delta sync, or removing the old server too soon, can result in lost messages or broken delivery.

MX Migration Requirements: What to Prepare Before You Start

Before you touch a DNS record, you need a complete picture of what you are moving and a fully prepared destination. Migrations that skip this phase tend to surface missing aliases or broken forwarders after the cutover, when fixing them is harder.

Here is what to have in place before you start:

A full inventory of your current email environment. List every mailbox address, alias, group address, and forwarder. Include any server-side rules that filter or redirect mail. These do not migrate automatically via IMAP, so they need to be documented and recreated manually on the new server.
New mailboxes provisioned on the destination server. Every address in your inventory needs a corresponding mailbox on the new provider before you change any DNS settings. Mismatches between old and new mailbox names cause delivery failures that are difficult to diagnose mid-migration.
Confirmed credentials and access for both servers. You need IMAP access credentials for every mailbox on the old server and admin access to the new server. Test these before the migration window. Discovering a locked account or an expired password during a live sync wastes time you do not have.
Admin access to your DNS zone. You will need to modify TTL values and MX records. Confirm who controls the DNS zone and that they are available during the migration window.
A clear scope and timeline. Know how many mailboxes you are moving and how large they are. According to Hostaccent's 2026 report, migrating one to five mailboxes requires approximately 90 minutes of active work spread over a three-day period. Larger estates take proportionally longer, and the initial sync for large mailboxes can run for several hours.
A plan for non-IMAP data. Forwarders, distribution lists, server-side rules, and calendar or contact data stored in proprietary formats do not move through an IMAP sync. Identify each item and document how it will be recreated on the new server.

Completing this checklist before you lower your TTL keeps the migration window clean and reduces the chance of discovering a gap when mail is already flowing to the new server.

What Role Does TTL Play in DNS Propagation?

TTL, or Time to Live, is the value in a DNS record that tells resolvers how long to cache it before checking for an update. When you change your MX record, resolvers that have already cached the old value will keep routing mail to the old server until their cache expires. A high TTL means that gap can last a long time.

The standard practice is to lower your MX record TTL to 300 seconds at least 24 hours before you plan to make the cutover. At 300 seconds, resolvers refresh the record every five minutes. That means once you update the MX record to point to the new server, most of the internet catches up within minutes rather than hours.

Even with a low TTL, full propagation is not instant. DNSimple notes that complete DNS propagation for updated MX records can take up to 48 hours. Some resolvers ignore TTL values and cache records longer than instructed. This is why the delta sync step exists: mail will continue to arrive at the old server during that window, and you need to capture it.

The practical sequence is: lower the TTL well before migration day, confirm the change has taken effect, then proceed with the remaining steps. Do not lower the TTL and immediately change the MX record in the same session. The point of lowering it early is to give resolvers time to start honoring the shorter cache window before you make the switch.

How Does IMAP Synchronization Differ from a DNS Routing Change?

Changing your MX record and synchronizing your mailboxes are two separate operations that solve two different problems. Conflating them is one of the most common reasons migrations result in missing messages.

An MX record change is a DNS update. It tells the internet where to deliver new incoming mail from the moment resolvers pick up the change. It does nothing to the messages already sitting on your old server. Those messages stay exactly where they are until you move them explicitly.

IMAP synchronization is the process that moves existing message data. An IMAP-to-IMAP migration tool connects to both your old and new mail servers using standard IMAP credentials and copies folders, messages, and read/unread states from one to the other. According to Hostaccent's 2026 report, a 500 MB mailbox can synchronize in minutes, while a 25 GB mailbox may require several hours. Plan your migration window around the largest mailboxes in your estate.

Because DNS propagation is not instantaneous, there is always a window after you update your MX record during which some senders are still routing mail to the old server. Mail delivered during that window will not appear on the new server unless you run a second synchronization pass after the cutover. That second pass is the delta sync, and it is what closes the gap between the two operations.

Neither step replaces the other. The MX record change redirects future mail. The IMAP sync copies historical mail. The delta sync captures what fell between them. All three are required for a complete migration.

Step-by-Step MX Migration Process

A complete MX migration follows a fixed sequence. Reordering the steps creates gaps. Here is the full process in the order you should execute it:

Inventory your current email environment. List every mailbox address, alias, group address, and forwarder on the old server. Document all server-side rules and filters. These items do not move through IMAP, so you need a written record before anything else happens.
Provision identical mailboxes on the new server. Create a matching mailbox on the destination server for every address in your inventory. Do this before you touch any DNS settings. If a mailbox does not exist on the new server when mail starts arriving there, those messages are lost.
Lower the TTL of your MX records to 300 seconds. Do this at least 24 hours before your planned cutover. This shortens the DNS cache window so that when you update the MX record, resolvers pick up the change in minutes rather than hours. Confirm the TTL change has propagated before you proceed.
Run the initial IMAP synchronization. Use an IMAP-to-IMAP migration tool or your new provider's migration utility to copy all existing messages from the old server to the new one. Start this sync before you change the MX record. A 25 GB mailbox can take several hours to copy, so run the initial sync during off-peak hours. Do not wait until the cutover window to start it.
Update your MX records to point to the new server. Once the initial sync is complete and you have confirmed the new mailboxes are receiving test messages correctly, update the MX record in your DNS zone. With a TTL of 300 seconds already in place, most resolvers will pick up the change within minutes. Full propagation can still take up to 48 hours, so expect a window during which some mail still arrives at the old server.
Run the delta sync. After the MX record change, run a second IMAP synchronization pass to copy any messages that arrived at the old server during the propagation window. This step is what prevents message loss during the gap between your DNS update and full propagation. Do not skip it.
Keep the old server active. Leave the old mail server running and the old mailboxes intact. The minimum floor is 48 to 72 hours after the MX record change, but keeping it live for several days is safer. Some senders cache DNS records longer than your TTL instructs, and mail can arrive at the old server days after the cutover.
Verify delivery and authentication. Send test messages from external addresses to confirm mail is arriving at the new server. Check that SPF, DKIM, and DMARC records have been updated. Confirm that forwarders and server-side rules have been recreated correctly on the new server.

For smaller estates, this process is manageable in a structured three-day window. For larger migrations, the timeline extends. A migration at UC Irvine involved moving 7,500 active accounts containing 22 TB of email data to new cloud providers, illustrating how the same sequence scales to enterprise scope.

How Do You Protect SPF, DKIM, and DMARC During a Host Switch?

Updating your MX record routes incoming mail correctly, but it does not update the DNS records that authenticate your outbound mail. If you switch mail hosts without updating SPF, DKIM, and DMARC, your outbound messages may fail authentication checks at receiving servers. Misconfigured authentication records after a host switch cause outbound mail to fail verification at receiving servers, which can result in messages being rejected or sent to spam before they reach the inbox.

Here is what to check and update at cutover:

SPF (Sender Policy Framework). Your SPF record lists the mail servers authorized to send on behalf of your domain. Add the new provider's sending infrastructure to your SPF record before you start sending from the new server. Remove the old provider's entries only after you have confirmed no mail is still originating from the old server.
DKIM (DomainKeys Identified Mail). Your new provider will give you a DKIM public key to publish as a DNS TXT record. Add this record before you begin sending from the new server. Keep the old DKIM key in DNS for several days so any in-flight messages signed with it can still be verified.
DMARC. If you have a DMARC policy set to reject or quarantine, confirm that your new server's sending addresses align with the updated SPF and DKIM records before going live. A misaligned DMARC policy will cause legitimate outbound mail to be rejected.

After cutover, use a DNS lookup tool to verify that all three records resolve correctly for your domain. Check the authentication headers in a received test message to confirm SPF passes, DKIM signs correctly, and DMARC aligns.

What Can Go Wrong, and How to Avoid It

Most MX migration failures trace back to a small set of skipped steps. Knowing them in advance is cheaper than diagnosing them after mail stops arriving.

The most common failure modes, and how to prevent each:

Forgetting forwarders and server-side rules. IMAP synchronization copies messages. It does not copy forwarders, distribution list memberships, filters, or auto-reply rules. If you do not document these before the migration and recreate them manually on the new server, they simply disappear. The fix is a complete inventory before you touch any DNS record.
Skipping the delta sync. DNS propagation can take up to 48 hours, and some resolvers cache records even longer. During that window, mail continues to arrive at the old server. Without a second IMAP sync pass after the MX record change, those messages never reach the new server. The delta sync is not optional; it is what closes the propagation gap.
Removing the old server too soon. The minimum floor is 48 to 72 hours after the MX record change, but several days is a safer target. Senders with long-cached DNS entries will keep routing to the old server well past that minimum. Decommission it too early and you lose whatever arrives after you pull it down.
Neglecting authentication records. Updating the MX record does not update SPF, DKIM, or DMARC. Leaving stale authentication records in place after a host switch causes outbound mail to fail verification at receiving servers. Update all three records at cutover and verify them with a DNS lookup tool before you consider the migration complete.
Mismatched mailbox names. If a mailbox exists on the old server but was not provisioned on the new one before the cutover, mail addressed to it has nowhere to go. A thorough pre-migration inventory, cross-checked against the new server before any DNS changes, prevents this entirely.

When Should You Bring in a Migration Partner?

For a handful of mailboxes, a careful IT administrator can execute an MX migration by following the steps above.

The calculus changes with size and interdependency. A migration like the one at UC Irvine, which involved 7,500 active accounts and 22 TB of email data, requires coordinated tooling, a tested rollback plan, and enough staffing to run delta syncs and monitor delivery across a large estate simultaneously. At that scale, a single missed step affects thousands of users.

Complexity adds a second threshold. Migrations that involve legacy mail platforms, custom routing rules, shared mailboxes tied to business applications, or simultaneous moves across multiple domains carry risks that a standard IMAP-to-IMAP tool does not fully address. When email infrastructure is entangled with other systems, the migration scope expands beyond DNS and mailboxes.

AspireNXT is a digital partner that works with organizations to plan and execute complex infrastructure migrations, including cloud workload moves and application modernization changes. For IT teams facing a migration at enterprise scale or with significant architectural complexity, working with a partner that handles end-to-end execution reduces the risk of the failure modes described above.

Prices and plan limits verified as of October 2026.

FAQs

How long does DNS propagation take after changing MX records?

Full DNS propagation after an MX record change can take up to 48 hours. Most resolvers will pick up the change faster if you lowered your TTL to 300 seconds at least 24 hours before the cutover. Even so, some resolvers cache records longer than your TTL instructs, which is why you should keep the old server active and run a delta sync after the MX update. Lowering the TTL early and running the delta sync together close the window where messages can fall through.

Can I migrate email without any downtime?

Yes, with the right sequence. Because you run the initial IMAP sync before changing the MX record, the new server already holds a copy of all existing messages when the cutover happens. New mail routes to the new server as resolvers pick up the updated MX record. The delta sync captures anything that arrived at the old server during the propagation window. Users can continue sending and receiving throughout.

Do forwarders and server-side rules migrate automatically via IMAP?

No. IMAP synchronization copies messages, folders, and read/unread states. It does not transfer forwarders, distribution list memberships, filters, auto-reply rules, or other server-side configuration. Document all of these during the pre-migration inventory and recreate them on the new server before the cutover.

How do I verify that my new MX records are working correctly?

Use a DNS lookup tool (such as a public MX record checker) to confirm that your domain's MX records resolve to the new server. Then send test messages from an external email account, one outside your domain, and confirm they arrive in the new mailboxes. Check the message headers to verify SPF passes, DKIM signs correctly, and DMARC aligns.

Should I delete the old mailboxes immediately after the cutover?

No. Keep the old mailboxes and the old server active for at least 48 to 72 hours after the MX record change, and ideally for several days. Senders whose DNS resolvers cached the old MX record will continue routing mail to the old server during that window. Decommission the old server only after you have confirmed that no new mail has arrived there for a full day or more, and check the old server's logs before you pull it down.

Conclusion

An MX migration is a sequenced process, not a single DNS change. Each step that prevents message loss, lowering TTL early, running the initial IMAP sync before cutover, executing the delta sync after, and keeping the old server live long enough, does a specific job. Skipping any one creates a gap that is difficult to close after the fact. Authentication records require the same attention: update SPF, DKIM, and DMARC at cutover, not as a follow-up task.

Before you start, complete the full pre-migration inventory and confirm that every mailbox, alias, and forwarder is documented and provisioned on the new server. If your estate runs to hundreds of mailboxes, involves legacy routing configurations, or sits inside a broader infrastructure modernization, assess whether the complexity warrants a managed approach. The failure modes in a large migration are predictable. The question is whether you have the tooling and staffing to handle them when they appear.