Migrating Custom Domain Email With Zero Downtime

Moving a domain's mailboxes from one provider to another sounds like it should be a single switch, but it is really a DNS event with real failure modes: bounced mail, a delivery gap, and outbound that suddenly fails authentication. The good news is that with the right order of operations, you can learn how to migrate custom domain email without downtime — no lost messages, and no visible gap for the people writing to you.

Your email addresses do not change in this kind of move. The domain stays the same. What changes is the MX record that tells the internet which server accepts mail for it, plus the SPF, DKIM and DMARC records that decide whether your sent mail is trusted.

This guide is provider-agnostic. The exact admin screens differ between Google Workspace, Microsoft 365, Fastmail, Zoho and the rest, and they change on their own release schedules, so it links to the vendors' live documentation for the click-by-click and focuses on the sequence that keeps mail flowing while you switch.

What actually moves — and what doesn't#

A custom-domain migration has two halves that people often conflate. One is inbound: where new mail is delivered, controlled entirely by the MX record. The other is your existing mailbox contents — years of mail, folders, read state, and sometimes contacts and calendar — which has to be copied across separately, usually over IMAP.

The MX change is instant to make and slow to spread. Copying mailbox contents is slow to run but touches nothing the outside world sees. Keeping those two facts apart is what makes a clean migration possible: you copy everything first, at your own pace, and flip the switch last.

Pre-migration checklist#

Most migrations that lose mail fail here, in preparation, not in the copy itself. Work through this before you touch a single DNS record — several items have to be true before the ones after them will work.

• Confirm you have edit access to the domain's DNS zone at the registrar or DNS host. MX, SPF, DKIM and DMARC all change, and discovering mid-cutover that someone else controls DNS is the classic stall.
• Check the current TTL on the MX record. Whatever it is now is how long old copies linger in resolver caches, so you lower it first and wait out the old value.
• Create every mailbox at the new provider with the exact address it has today, before copying anything. An IMAP import has nowhere to land without the target mailbox already existing.
• Inventory mailbox sizes. A 40 GB mailbox's first IMAP pass can run for many hours; knowing that up front tells you when to start.
• Collect the new provider's SPF include, DKIM selector records and recommended DMARC value now, so publishing them at cutover is a paste, not a research task.
• List every server-side filter, alias, forward and autoresponder on the old provider. None of these travel over IMAP — you recreate them.
• Decide how you'll handle residual mail — forwarding from the old provider to the new, or a final catch-up sync — before, not during, the cutover.
• Tell users the cutover window and ask them not to change server-side filters or delegate settings during it.

The migration steps#

1. 1

   Lower the MX record TTL

   At least 24 to 72 hours before cutover, drop the MX record's TTL to a low value such as 300 seconds. A short TTL is the only control you have over propagation speed — but it only takes effect after the previous TTL has expired everywhere, which is why you do it days ahead, not on the day.

2. 2

   Provision mailboxes at the new provider

   Create each mailbox with its exact current address. An IMAP import has nowhere to deliver otherwise, and Microsoft's documentation notes plainly that IMAP migration does not create the mailboxes for you.

3. 3

   Copy existing mail over IMAP

   Point the new provider's import tool at the old server over IMAP and run the first full pass while the old provider still receives live mail. Nothing the outside world sees changes yet — this is a copy, not a cutover.

4. 4

   Publish the new SPF, DKIM and DMARC records

   Add the new provider's SPF include, publish its DKIM selector records under _domainkey, and confirm your DMARC record still aligns. Do this before or at cutover so your first outbound from the new provider passes authentication.

5. 5

   Cut the MX record

   Repoint MX at the new provider's mail exchanger. This is the only step that redirects new mail. From here, delivery shifts to the new server as each resolver's cached MX expires — fast for most, slower for a few.

6. 6

   Run the dual-delivery window

   For as long as propagation lasts, both servers may receive mail. Keep both mailboxes live and either forward residual mail from the old provider to the new one, or run repeated IMAP catch-up passes so nothing is stranded.

7. 7

   Run a final catch-up sync

   Once the MX change has fully propagated and no new mail is arriving at the old server, run one last IMAP pass to pull anything that landed there during the window.

8. 8

   Decommission the old provider last

   Only after the final sync — and ideally a trailing week or two of monitoring — cancel or downgrade the old mailboxes. A deleted source mailbox is the one step in this list you cannot cleanly undo.

What breaks during an MX change#

Almost every failure in a domain migration is a timing or record problem, not lost data — which is also why the sequence above prevents most of them. These are the ones worth planning around.

The dual-delivery window, visually#

The single idea that makes zero-downtime migration work is that an MX change is not atomic. For a stretch of time — bounded by the TTL you set — some mail servers on the internet still deliver to your old provider while others have already picked up the new one. Nothing is lost as long as both mailboxes accept mail and you reconcile what landed where.

This is why the plan keeps both providers receiving through the transition instead of switching instantly. The overlap is the safety net, not a mistake.

Rollback plan#

A domain migration is close to fully reversible right up to the MX cutover, and stays reversible for a while after — as long as you kept the old provider active. The whole rollback plan is one rule: don't cancel the source until you're sure.

• Before MX cutover: there is nothing to roll back. The old provider is still authoritative for delivery; the copied mail at the new provider is only a copy.
• Right after cutover, if delivery breaks: point MX back at the old provider. It takes the same TTL-bound time to propagate back as it did forward — another reason the low TTL matters both ways.
• Keep the old provider's SPF include in place a little longer rather than removing it the instant you cut over. Pulling it too early is a common self-inflicted bounce.
• Set a rollback trigger in advance — for example, more than a handful of missing-mail reports in the first few hours — and name who has the authority to call it.
• Don't delete the old mailboxes for at least a couple of weeks. A cancelled mail plan is not reversible the way a DNS record is.

Doing it without downtime#

"Zero downtime" does not mean the change is instant — it means no message is ever bounced or lost while DNS propagates. You get there by giving the old and new providers a deliberate overlap, not a hard switch.

Lowering the MX TTL ahead of time shrinks the propagation window; keeping both mailboxes live through it means mail delivered to either server has somewhere to land. Forwarding residual mail from the old provider to the new one — or a final IMAP catch-up pass — closes the gap so nothing is stranded on the old server after the change settles.

Test on a subdomain first. Point a routing subdomain such as mail-test.yourdomain.com at the new provider's MX and send real messages through it before touching the root domain's record. It proves the new mailboxes, SPF and DKIM work while the blast radius is zero.

Cut over during your quietest hours — a Friday evening or weekend for most teams — so the propagation window overlaps the least mail. Run one canary mailbox a day ahead of the rest, so a broken DKIM record or a missing alias surfaces on one inbox instead of the whole domain.

Watching both inboxes during the overlap#

This migration moves the mailbox; it does not choose the client you read it in. And a domain cutover is exactly the moment that question comes up, because for a week or two some of your addresses are settling on the new server while residual mail still trickles into the old one, and someone has to watch both.

AI Emaily connects to Gmail, Outlook and any IMAP mailbox through the same account model this migration already sets up, so it shows the old and the new provider in one unified inbox while delivery converges — you're not logging into two webmails to make sure nothing was missed, with undo and an audit trail on every action and no training on your mail. It will not perform the migration for you; the steps above do that. We build AI Emaily, and we name it here because "which inbox do I watch during the overlap" is a real question this plan creates.