How to Move Email to a New Domain Without Losing Mail (2026)

Moving email to a new domain means standing up the new domain's mail setup completely, syncing old mail across with IMAP, then flipping MX records in a quiet window while the old domain keeps catching anything misrouted. Two rules prevent nearly all lost mail: build the destination before you change DNS, and keep the old domain active for weeks after the switch, not days. Those two rules come from migration guides written by people who run mail infrastructure, and every disaster story in this area traces back to violating one of them.

This is a rebrand or consolidation move, the rename from acmecorp.com to acme.com. It is not the same job as switching providers on the same domain, which keeps every address and changes only the MX records behind them; here the visible addresses themselves change. If instead you are keeping the provider and adding domains, see email hosting for multiple domains.

The three phases, in order

Domain migrations fail when the order is wrong. The correct sequence:

1. Build (days before). Register the new domain if you have not. Create every mailbox and alias on the new domain at your mail host. Set up SPF, DKIM, and DMARC for it. Do not touch DNS on the old domain yet.
2. Sync (days before, can run long). Copy existing mail from the old mailboxes to the new ones with IMAP sync, so history travels with you. Run the bulk sync early; it is the slow step.
3. Cut (the quiet window). Publish the new domain's MX records and update anything that sends as the old domain. Then verify and monitor.

The reasoning behind the order is mechanical: MX records are the switch that routes inbound mail, and pointing mail at mailboxes that do not exist yet is how mail gets bounced. MonoVM's migration guide states the principle as building the destination environment before any traffic moves, and lowering DNS TTL to 300 seconds roughly 24-72 hours before cutover so the flip propagates fast.

Phase by phase, what to actually do

Build: inventory before you create

List everything on the old domain before recreating it: every mailbox, every alias, every forwarding rule, every catch-all. Migration tools move mailbox contents; they do not move routing rules, so aliases and forwards need manual recreation on the new domain. Absolute Email's provider-switch guide makes the same point for the provider-switch case, and it applies doubly to domain moves.

Create the matching addresses on the new domain at the host that will run it. If you use role addresses (and you should), this is the moment to standardize: hello@, support@, billing@ on the new domain even if the old one had accumulated variants. Our catch-all vs email aliases comparison explains why explicit aliases beat a catch-all for steady-state domains.

Authentication comes next, per domain: SPF authorizing the sending servers, DKIM signing outbound, DMARC policy. This is non-negotiable on a new domain because receivers have no history with it. The record-by-record version is in our SPF, DKIM, and DMARC explainer, and the ordered version in the setup checklist.

A brand-new domain also needs warmup before it sends at volume: 4-8 weeks of gradually increasing volume is the realistic figure, and dormant domains need the same ramp. The full schedule is in how to warm up an email domain.

Sync: move the history with IMAP

Mail does not move itself. The workhorse method is IMAP sync: both old and new accounts online, a sync tool copying folders and messages from one to the other. The pattern from MonoVM's guide:

1. Run the initial full sync days ahead of cutover, because large mailboxes take hours.
2. Verify folder structure and message counts on the new side.
3. Just before cutover, run a final delta sync to catch mail that arrived since.

POP3 accounts are the exception: mail stored client-side by POP needs an export/import through the mail app rather than a server-to-server sync.

Cut: flip MX, then watch

In your quiet window (a weekend works for most small teams):

1. Confirm TTL is low on the old domain's records, so caches expire quickly.
2. Point the new domain's MX records at the mail host. This is the moment new inbound mail starts arriving on the new domain.
3. Update SPF, DKIM, DMARC for any system still sending as the old domain during the transition.
4. Test ruthlessly: send in and out of the new addresses from Gmail, Outlook, and Yahoo accounts; check authentication headers on received test messages; check bounce logs.
5. Keep the old domain's mail path alive. MonoVM's guidance: keep the old provider active at least 24-72 hours, or longer, until mail flow is verified across all users and clients. For a domain rename, plan on weeks, not hours, because mail from stale contact lists and old invoices keeps arriving at the old domain for a long time.

The old domain is also your safety net for the misspelled and the out-of-date. This is the one scenario where a temporary catch-all on the old domain, feeding a quarantine inbox you sweep weekly, is a defensible pattern; the spam trade-offs are laid out in catch-all email spam risk. Promote the addresses that keep receiving real mail to aliases on whichever domain now owns that function, then close the wildcard.

What breaks when this goes wrong

• MX pointed at nothing. Mail for the new domain bounces at the edge because no mailbox matches the recipient. Build first, always.
• Aliases silently missing. Nothing errors; mail to support@newdomain.com just never arrives anywhere a human reads. The inventory step exists to prevent this.
• Authentication half-migrated. SPF includes the old host, DKIM keys unpublished, DMARC unconfigured: outbound mail from the new domain lands in spam. Check headers on a live test, not assumptions.
• Old domain cancelled early. Registrar expiry or cancelling the old hosting kills the catch-all for stragglers. Renew the old domain through the transition plus a buffer; it is the cheapest insurance in the whole operation.

Migration is the natural consolidation moment

A domain move is downtime you were going to have anyway, which makes it the cheapest moment to fix the structure around the move. If the old setup was one provider per domain, or per-product domains scattered across accounts, the new domain can land on a host that already runs the others. SuperMailOS is built for exactly that shape: you bring your domains, it runs the mail server and deliverability (SPF, DKIM, DMARC, IP reputation, warmup) on all of them, with one-click DNS on Cloudflare, DigitalOcean, Linode, Vultr, Hetzner, and Spaceship, typically under five minutes per domain, and a web inbox with IMAP/SMTP for any mail app. Aliases are free and unlimited on every plan, so standardizing hello@, support@, and billing@ on the new domain costs nothing extra; the pricing is per person, not per address. Agencies moving client domains have a second layer of handover questions, covered in email hosting for agencies.

Frequently asked questions

Can I move email to a new domain without losing messages?

Yes, if you sequence it: create all mailboxes and aliases on the new domain first, sync existing mail across with IMAP before cutover, then switch MX records, and keep the old domain receiving during validation. Lose any one of those and mail goes missing silently rather than loudly.

How long does an email domain migration take?

The DNS cutover itself takes minutes once TTL is lowered. The safe envelope is longer: days for the IMAP sync of existing mail, and weeks of keeping the old domain alive to catch stragglers from stale contact lists and old threads.

Do I need to tell customers my email address is changing?

Yes, for a domain change. The visible address changes with the domain, so every contact, vendor, bank, and login that used the old address needs the new one. Sending the notice from the new address while the old one still works is the standard pattern.

Should I keep the old domain running?

For weeks at minimum. Old threads, mailing lists, and printed addresses keep sending to the old domain long after a rename. Keep its MX records live, forward or catch what arrives, and promote recurring real mail to proper aliases before shutting it down.

Will my new domain's mail land in spam initially?

It sends with no reputation, so volume discipline matters from day one. Authentication records must be in place before the first send, and a ramp of gradually increasing volume keeps placement healthy. Our domain warmup guide has the week-by-week schedule.

---

Moving a domain and want the new one to land on infrastructure that already handles the rest? SuperMailOS runs mail, authentication, and warmup for every domain you bring, with unlimited free aliases and one bill per person. 14 days free, no credit card.