Moving a name · Intermediate · 1–2 hours, or one support ticket
How to migrate email to new host — Mail Migration Is a TTL Problem Wearing a Mailbox Costume
Mail migrations do not fail on the copying. They fail on the order the records were changed in, and on a cache timer nobody thought to lower the day before.
The short answer
Moving mailboxes safely is a question of sequence and of clocks: lower the MX record's TTL a day ahead, create every destination mailbox before a single record changes, sync the history over IMAP, then change the MX with the old server still accepting, and sync again once the old TTL has expired. Allow 1–2 hours, or hand it to us as one support ticket.
Everything that strands mail comes from breaking that order. Change MX before the destination mailboxes exist and messages arrive at a server with no matching account. Shut the old server down before the caches have expired and you lose whatever was still being delivered there.
By the Hosting & Domains team · Reviewed 24 August 2026
Intermediate
Level assumed
Quick
Time to allow
5
Stages to work through
24/7
Desk hours
Written for whoever holds the name rather than for whoever runs the server. Registry, registrar, DNS host and mail host are kept apart throughout, because most of the confusion in this subject comes from treating the four as one thing.
Nothing on this page is a one-way door. Where a change carries a clock with it — a cache timer, a registry lock, a renewal date — the page says so before you act rather than afterwards.
Order of operations, because there is nothing else
A mail migration has almost no technical difficulty in it. Mailboxes are created, messages are copied, records are changed. Every published horror story about lost mail is a story about doing those three in the wrong order.
The order that works is: destination first, history second, delegation third, sweep fourth. Nothing below is more complicated than that, and nothing below is safe to reorder for convenience.
Drop the TTL the day before
The TTL governing any change is the one that was already in force when you made it. Change an MX record carrying a four-hour TTL and resolvers around the world will go on handing out the old answer for up to four hours, no matter how quickly you saved it.
So the drill is: a day ahead, take the TTL on the MX records and any autodiscover entries down to five minutes. Make the change on the night. Put the TTLs back up the following morning. Propagation then runs to your timetable rather than to yesterday's.
The destination has to exist before the delegation moves
Recreate every address at the new host, empty and waiting, before you touch a record. A sending server that follows a new MX to a host with no matching account gets a rejection on the spot, and that rejection goes straight back to the person who wrote to you.
Take an inventory while you are there. Screenshot each account's folder counts before anything moves; thirty seconds of that turns 'I think it all arrived' into a checklist you can verify folder by folder afterwards.
Overlap: both ends accepting while the clock runs
Change the MX records with the old server still in service. For the length of the old TTL, some senders will use the new host and some the old, and both will accept. Mail in flight retries and lands somewhere reachable rather than bouncing.
The old mailboxes stay live until you are certain nothing further is arriving there. Losing mail in a migration takes actively shutting the old server down early, which is why the only genuinely dangerous instruction in this whole process is 'cancel the old hosting'.
The second sync is what makes 'nothing lost' true. Once the old TTL has expired and everything resolves to the new host, run the IMAP sync a second time. It gathers whatever landed on the old server during the overlap and puts it where the user will look for it.
Only then does the old service come down. That second pass is the difference between a migration that is finished and one that merely appears to be, and it takes minutes.
Clients, autodiscover, and the names in the settings. If everybody was already using the mail.yourdomain pattern, most clients need nothing done to them: the hostname is unchanged and only the machine behind it moved. Passwords may need re-entering; the history is already in place.
Where clients were configured against the old host's own hostname, each device needs the server names updating. Moving to your own domain's hostnames at the same time is worth the extra half hour, because it makes the next move a DNS change rather than a tour of everyone's phone.
Sensible defaults, shorter instructions
Every walkthrough here was carried out on the platform we operate — cPanel, LiteSpeed, NVMe, one-click installs — against a domain delegated to our own nameservers, so the screens described are the screens you get.
Every plan is copied daily, and putting a file or a database back is one click in the panel rather than a ticket and a wait.
- Which panel holds which power, said plainly
- The step that silently does nothing, flagged early
- Defaults left alone wherever the defaults are right
- Somebody on the desk at any hour
Why Hosting & Domains
Standard on every plan
Registry, registrar, host — kept apart
Each term is defined where it first appears, or linked to the jargon buster. Nothing here uses the four words as though they meant one thing.
Help on your clock, not ours
Stuck at the zone editor at midnight? The desk answers at any hour, mid-walkthrough included.
Written out of the ticket queue
These pages exist because the same questions kept arriving. Every warning on them is one somebody has genuinely needed.
Checked at the panel, not imagined
Every instruction was carried out on the platform we run, against a name delegated to our own nameservers. No 'your provider may differ' hedging.
The silent failure, named first
The mistake this task actually produces is described before step one, which is how 1–2 hours, or one support ticket stays 1–2 hours, or one support ticket.
The parts the account already handles
Certificates, daily copies and application installs look after themselves, so the page only covers what is genuinely yours to decide.
Quick Start
Order placed to site online
- 1
Lower the MX and autodiscover TTLs a day ahead
Take them down to five minutes the day before. The TTL in force at the moment of the change is the one that governs it, so this is the one step that cannot be done on the night.
- 2
Recreate every mailbox at the destination, empty
Same addresses, waiting and unused, before a single record changes. Note each mailbox's folder counts at the old host while you are there — it becomes the checklist you verify against later.
- 3
Run the first IMAP-to-IMAP sync
A sync tool, or our migration team at no charge, mirrors folders, flags and structure from the old server to the new. Nothing short of a full IMAP pass carries the whole history across intact.
- 4
Change the MX records with the old server still accepting
Both ends live, for at least the length of the old TTL. Senders resolve to one or the other and both take delivery, so mail in flight lands rather than bouncing.
- 5
Sync again once the clock has run, then repoint the clients
A second IMAP pass sweeps up whatever reached the old server during the overlap. After that, update server names on each device, or leave them alone entirely if they already point at mail.yourdomain.
Built In
Fitted to every plan
- WordPress and 400+ other applications in one click
- Your existing site brought across by our engineers at no charge
- No set-up charge at any point, and no joining fee
- DDoS filtering absorbed at the network edge
- PHP set per name from the panel, not once per account
- Softaculous bundled, for one-click application installs
- WebP image optimisation built in, at no extra charge
- A renewal figure identical to the one you registered at
- Mailboxes that answer at the name you hold
- cPanel, the panel most of the industry already standardised on
Frequently Asked
Questions we field again and again
How long do the old mailboxes have to stay running?
At minimum until the TTL that was in force before the change has fully expired, and comfortably longer than that. Sending servers retry for hours or days, so anything that failed during the switch will keep trying; leaving the old end accepting for a week costs nothing and removes the only way this job actually loses mail.
Does moving mail hosts mean moving the domain as well?
No, and the two are worth keeping separate in your head. The registrar holds the registration, the nameservers hold the zone, and the MX records inside that zone name the mail host. You can change the mail host by editing two or three records without the registration or the delegation moving at all — and that is usually the calmer way to do it.
Can your team run the mailbox migration for us?
We can, free with hosting, covering the IMAP history sync and the DNS sequencing. Mail migration is precisely the job where doing it before has more value than reading about it, so handing it over and spending the afternoon on something else is a reasonable choice.
If I cancel, what happens to my files and my names?
They stay yours. A full copy is downloadable from the panel whenever you want it, before or during a cancellation. Names remain registered in your name for the term you paid for, and can be transferred to any other registrar once the standard 60-day window has passed.
Keep reading
SSL Certificates
Free SSL on every plan, with wildcard and EV available when a name needs more.
WordPress Hosting
WordPress looked after for you: LiteSpeed caching, staging copies and a daily backup.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
One rate, this year and next.
NVMe hosting with the certificate and the migration included, people answering at any hour, and a renewal figure that does not move.
View SSL Certificates plans