Guide Email

How to keep email working during a migration

The sequence that stops email being lost or delayed while a domain and its mailboxes move to a new host.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Email problems during a website migration are almost always self-inflicted by the order things were done in, rather than an unavoidable side effect of moving. Get the sequence right and mailboxes can keep working throughout, with no window where mail is lost.

The core rule: never point MX records at a destination before it is ready

MX records tell the world where to deliver mail for your domain right now, immediately, the moment they finish spreading. If they are changed before mailboxes exist and are ready at the new destination, incoming mail during that gap has nowhere correct to land. Every step below exists to make sure that never happens.

A full nameserver change moves email whether you meant it to or not

If a website migration involves switching the domain's nameservers rather than just an A record, every DNS record moves at once — including MX. This is the single most common way email breaks during what was meant to be only a website move. If email must stay exactly where it is during a site migration, use an A record change instead of a nameserver change; see pointing a domain to your hosting for the difference between the two methods.

If email is staying where it is

The simplest and safest option, when only the website is moving: leave the domain's MX records completely untouched, and move only the A record that points the website. Email continues exactly as before, with zero disruption, because nothing about its configuration changed. This is the recommended approach whenever the new host is not also taking over email.

If email is moving too

Follow this order precisely:

Create every mailbox on the new host first
Set up matching addresses on the new hosting account before anything else happens. Nothing about the domain's live DNS changes at this point.
Copy existing mail across while both mailboxes are active
See migrating mailboxes to a new host for the specific methods. This can take as long as it needs to, since the old mailboxes are still receiving mail normally throughout.
Lower the MX record's TTL in advance
A day or so before switching, reduce the TTL to around 300 seconds so the eventual change spreads quickly rather than over many hours. See how long DNS propagation takes.
Switch MX records only once the new mailboxes are fully ready
Confirm mail has been copied and the new mailboxes are accessible before making this change — it is the point of no return for where new mail starts arriving.
Keep the old mailboxes reachable for a short overlap
Do not delete or disable the old accounts immediately. Some mail servers around the world will still be using the old MX record for a short period while the change spreads, and anything sent during that window needs somewhere to land.

Timing the cutover

If possible, schedule the MX switch for a genuinely quiet period — outside business hours, or a time when little mail is expected — rather than in the middle of the busiest part of the day. This is not strictly necessary if the steps above are followed correctly, but it reduces the consequences of any unexpected issue during the change itself.

What to check immediately after switching

Send test messages to each migrated address from an external account and confirm they arrive at the new mailbox.
Check the old mailbox briefly, a day or two later, for anything that arrived during the propagation window.
Update every device's mail app with the new server settings — see the setup guides for Outlook, iPhone, Android and Apple Mail.

Communicate the change if the mailboxes matter to other people

If a team relies on shared mailboxes, letting people know roughly when the switch will happen — and to expect brief settings prompts on their own devices afterwards — avoids a flurry of "email isn't working" reports during a change that is actually proceeding normally.

Done in this order, there is no point at which mail has nowhere to go — old mail keeps arriving at the old server until the MX change spreads, and new mail starts arriving at a destination that has been ready and waiting the whole time.

What if the website and email are moving to different hosts

This is a common and entirely workable arrangement — nothing about the steps above requires email to move to the same place as the website. If the website is moving but email is staying with its current provider, simply leave the MX records untouched throughout the whole website migration and change only the A record that points the site. See pointing a domain to your hosting for how to move only the website side safely.

If something does go wrong mid-migration

Should new mail stop arriving unexpectedly during the process, check the MX record first — confirm it currently points where you intend it to, and that the destination mailboxes it points at actually exist and are ready to receive. If the new destination is not yet ready, the record can be reverted to the old value while the destination is prepared properly, since nothing about this process is irreversible until you are satisfied it is working.

Do not delete the old mailboxes until you are certain

Deleting old mailboxes immediately after switching MX records removes your ability to revert if a problem appears afterwards, and closes off the overlap window where late-arriving mail from before the DNS change fully spread would otherwise still be caught. Wait until you have confirmed test mail is arriving reliably at the new destination before removing anything on the old one.

A well-planned email migration, following the sequence above, should be invisible to everyone except whoever is carrying it out — senders notice nothing, and recipients see no gap in what arrives.