How to Change Email Hosting Without Downtime

Moving a domain’s email to a new host scares people more than moving the website. A website that is down for ten minutes comes back. An invoice or a signed contract that disappears during the switch might never be sent again, and nobody notices until someone asks why they got no reply. You can change email hosting without downtime, and without losing a message, if you do the steps in the right order and keep the old account alive a little longer than feels necessary.

This guide is for small-business owners and for whoever looks after their domain. It covers moves from one cPanel host to another, from a registrar’s bundled mail, and between Google Workspace or Microsoft 365 and cPanel mail, in either direction. The DNS mechanics are the same in every case. Only the place you copy the mail from changes.

What “downtime” really means for email

Email does not work like a website. When someone sends a message to [email protected], their mail server looks up the MX records for example.com, connects to whichever server those records name, and hands the message over. If that server cannot be reached, the sender does not give up. It queues the message and keeps trying. Most mail servers retry for four or five days before they bounce a message back to the person who wrote it.

So a few hours where nothing answers usually goes unnoticed, apart from messages arriving a little late.

The real risk during a migration is different. After you change the MX records, resolvers around the world keep the old answer until its TTL (time to live) runs out. For that window some senders deliver to the new server and some still deliver to the old one. Nothing is lost at that point, but it lands in two places. Mail actually goes missing in two situations:

• The old account is closed or the domain is removed from the old server while some senders still use the old MX. The old server now rejects those messages, and the senders get a bounce they may never read.
• The old account stays open but nobody looks at it again, so the messages that landed there sit unread until the account expires.

Most of the rest of this guide is about avoiding those two, and about making sure people can still read and send mail on the day.

Before you start: an inventory

Before touching DNS, spend twenty minutes writing down what exists today, because the forgotten pieces are what break afterwards. List every mailbox on the domain, plus every forwarder, alias, group address and autoresponder. People forget the info@ that forwards to three colleagues until it stops working. Write down the current DNS records too, at least MX, SPF (the TXT record starting v=spf1), DKIM, DMARC, and anything named autodiscover, autoconfig, mail or webmail. A screenshot of the DNS zone is enough.

Then ask one question of everybody who uses the mailboxes: are you set up with IMAP or POP3? A POP3 client usually downloads mail and deletes it from the server, so for a POP3 user the only full copy of years of mail is on one laptop. No server-to-server copy will find it. Those users need to move their local mail separately, or switch the account to IMAP and upload their folders before you migrate.

Finally, find out where DNS is hosted. It might be at your registrar, at Cloudflare, or on the old host’s nameservers. That is where you will edit records on cutover day, and it changes the plan slightly, as the next section explains.

Lower the TTL 24 to 48 hours ahead

The TTL tells resolvers how long they may cache a record. Typical MX records carry a TTL of one hour, four hours (the usual cPanel default is 14400 seconds) or a full day. If you change an MX record with a four-hour TTL, some senders will keep using the old server for up to four hours.

A day or two before the move, set the TTL on the MX records to 300 seconds, and on the SPF, autodiscover and mail hostname records too if your DNS editor allows it. Do not change the values yet. The point is that by cutover day every cache in the world holds a copy that expires within five minutes.

The lowered TTL only starts working after the old one has run out, which is why this has to happen well ahead of time. A record that had a 24-hour TTL needs a full day before the new short TTL is what resolvers hold.

If you are also moving nameservers (say, from the old host’s nameservers to the new host’s), this trick does not cover the move itself. The nameserver delegation is held by the registry for your domain’s extension, and for .com that TTL is two days and outside your control. In that case make sure the zone at the new host is complete and correct before you change nameservers, and expect both servers to receive mail for up to 48 hours. It is often simpler to keep DNS where it is during the email move, change only the MX records, and move nameservers on a quiet week later.

Create the mailboxes on the new host first

Every address that receives mail today has to exist on the new host before the MX records change. Use exactly the same addresses. If a sender reaches the new server and [email protected] does not exist there, the message is refused and bounced. Along with closing the old account too early, that is one of the two ways mail genuinely gets rejected in a migration, and both are avoidable.

In cPanel, mailboxes are created under Email > Email Accounts. Forwarders live under Email > Forwarders, autoresponders under Email > Autoresponders. Set the mailbox quota high enough for the mail you are about to copy in. A quota smaller than the old mailbox makes the copy stop partway through, and people only notice when their 2021 folder turns out to be empty.

You will need each mailbox password for the copy. Setting the same passwords as on the old host makes the client changeover easier for staff, but only do it if those passwords are strong. A migration is a good moment to replace weak ones.

Copy the existing mail over IMAP

With the mailboxes in place, copy the history across while the old server is still the live one. Nobody is affected while this runs, and it can take hours for large mailboxes.

imapsync, for anything more than a mailbox or two

imapsync connects to both servers as a normal IMAP client and copies folders, messages and flags. It runs on any machine that can reach both servers, which includes your own laptop or a small Linux server. You do not need shell access on either host, and that matters because shared hosting plans often do not offer it. It is available as a Perl script and as a Docker image.

imapsync \
  --host1 old-mail.example.net \
  --user1 [email protected] \
  --passfile1 ./old.pass \
  --host2 new-server.example.org \
  --user2 [email protected] \
  --passfile2 ./new.pass \
  --ssl1 --ssl2

--passfile1 and --passfile2 read the passwords from files so they do not end up in your shell history. Add --dry for a first run that only reports what it would do.

Point --host2 at the new server’s own hostname, not at mail.example.com. Until the cutover, mail.example.com still resolves to the old host, and you would be copying the mailbox onto itself. Your new host’s welcome email or support team can give you the server name. In cPanel it is also listed on the Server Information page.

Google Workspace and Microsoft 365 need extra care as a source. Microsoft has switched off plain password logins for IMAP in Exchange Online, so imapsync needs an OAuth2 token there. Google accounts need an app password, which requires 2-Step Verification, or OAuth2. Gmail also exposes labels as folders and keeps a copy of every message in All Mail, so exclude that folder or you will copy most of the mailbox twice. The imapsync documentation has dedicated notes for both providers, and they are worth reading before the first run.

A mail client, for one small mailbox

For a single mailbox of a few gigabytes, an email client is fine. Add the old account and the new account to Thunderbird or Outlook as two IMAP accounts, again using the new server’s hostname for the new one. Then drag each folder from the old account to the new one and wait for the client to finish uploading before you close it. It is slow and needs watching, but it does the job without any extra software.

cPanel to cPanel

If both hosts run cPanel, the mail can travel with the rest of the account. A full cPanel backup contains the mailboxes, and the receiving host restores it from WHM or pulls the account with WHM’s Transfer Tool. You still need the final sync described below, because the backup is a snapshot of one moment.

Cutover day: change the records in this order

Pick a quiet time. For most small businesses that is late on a Friday or early on a weekend morning, though any time works once the TTL is low. Then change the records in this order.

1. MX records. Replace the old MX records with the new host’s, with the priorities your new host gives you. Delete the old ones rather than leaving them at a lower priority, otherwise senders will keep using them whenever the new server is slow to answer. From this point new mail starts arriving at the new server.

2. SPF. A domain can have only one SPF record, so edit the existing one instead of adding a second. During the changeover it should list both the old and the new senders, for example v=spf1 +a +mx +ip4:203.0.113.10 include:spf.protection.outlook.com ~all when you leave Microsoft 365 for a cPanel server at 203.0.113.10. Take the exact values for the new host from its documentation or from cPanel, as described below. Remove the old provider about a week later. Remember the other systems that send as your domain, such as the website’s contact form, an invoicing tool or a newsletter service. They need to stay in the record.

3. DKIM. The new host signs outgoing mail with its own key, published under a selector. cPanel uses the selector default, so its key lives at default._domainkey.example.com. Google uses google and Microsoft uses selector1 and selector2, which means you can publish the new key next to the old one without a clash. Moving between two cPanel hosts is the awkward case. Both want default._domainkey, so the key changes at the moment you switch, and anything the old server still sends after that fails DKIM. Change that record at the same time as people start sending from the new server, not hours before.

4. DMARC. The _dmarc record usually does not need to change, but check its policy. If it says p=reject and you are not sure the new SPF and DKIM are right yet, relaxing it to p=quarantine or p=none for the changeover week costs little. Put it back once the reports look clean. Our guide to setting up SPF, DKIM and DMARC in cPanel explains what each record does and how to read the reports.

5. Autodiscover and autoconfig. Outlook looks up autodiscover.example.com, and Thunderbird and some other clients look up autoconfig.example.com, to find server settings automatically. Leaving Microsoft 365 means removing or repointing the autodiscover CNAME that points at autodiscover.outlook.com. If you skip that, Outlook keeps finding the old service for weeks. cPanel normally creates its own autodiscover and autoconfig records when it hosts the DNS. If your DNS lives elsewhere, add them by hand, pointing at the new server.

6. Mail and webmail hostnames. Point mail.example.com and webmail.example.com at the new server so the addresses people type and the settings their phones use lead to the right place. The new host also needs those names in DNS before it can issue an SSL certificate for them. Give it a little while after the change before you treat a certificate warning as a fault.

If you use cPanel on the new host with its nameservers, the Email > Email Deliverability page shows what it expects for SPF and DKIM and can fix the records for you with its Repair button. When DNS is hosted elsewhere, the same page shows the values to copy.

Leaving Google Workspace or Microsoft 365 has one extra trap. Inside the old tenant, mail between colleagues does not look at the public MX records. As long as the domain is still set up there, anyone who sends from an old account to a colleague delivers into the old mailbox. Move everybody over on the same day and remove the domain from the old tenant once the final sync is done.

The final sync

Over the next day or so, some mail will still land on the old server, sent by people whose resolvers held the old MX or by servers retrying a message they queued before the change. Once the new MX has been in place long enough for the old TTL to run out twice, run imapsync again with the same command. It skips messages it has already copied and brings across only what arrived since the first run.

Run it once more a few days later. It takes a minute, and the stragglers it finds are usually the messages people would have asked about.

Keep the old account for a week or two

Do not cancel the old email hosting the day the MX changes. Keep it running for one to two weeks, with every mailbox intact, so that anything that still arrives there is accepted and can be synced. Cancelling early is the most common way an email migration actually loses mail, because the old server starts rejecting messages for a domain it no longer hosts.

Set a calendar reminder for the cancellation date, and do one last check of the old mailboxes for new messages before you cancel.

Update mail clients and phones

Once the MX records point at the new host, each person’s devices need the new settings. Most of the time that means editing the incoming and outgoing server names and ports in the existing account, or removing the account and adding it again.

On GoZen’s cPanel hosting the settings are the same for every mailbox:

Setting	Value
Incoming server (IMAP)	mail.yourdomain.com, port 993, SSL/TLS
Outgoing server (SMTP)	mail.yourdomain.com, port 465, SSL/TLS
Username	The full email address

cPanel’s Connect Devices page, reached from Email Accounts, lists the settings for each mailbox and offers automatic setup for some clients. Phones are the devices people forget. A phone still pointed at the old server shows an inbox that slowly stops filling, and its owner thinks email is broken. Check them all, including the shared tablet at reception.

A client that is switched from one IMAP server to another normally downloads the whole mailbox again, which can take a while on a large account. Warn people so they do not interrupt it.

How to check that it worked

Start with DNS. From a terminal:

# What the world sees for your MX records
dig MX example.com +short

# Ask two public resolvers and see the remaining TTL in the second column
dig MX example.com @1.1.1.1 +noall +answer
dig MX example.com @8.8.8.8 +noall +answer

# Check the SPF record
dig TXT example.com +short

On Windows, nslookup -type=mx example.com gives the same answer for MX records. Every query should return the new host’s mail servers and nothing from the old one.

Then send a test message from an outside account, such as a personal Gmail address, to one of the migrated mailboxes. It should appear in webmail on the new host. Reply to it from the new mailbox and open the reply in Gmail with Show original. Near the top you will see SPF, DKIM and DMARC results, and all three should read PASS. Further down, the Received: headers record each server the message passed through, newest at the top. In the reply, the sending server named there should be the new host, not the old one.

Do the reverse check on the old server too. Log in to its webmail the next morning. If new messages are still appearing, some senders have not caught up yet, and the final sync will bring them over.

Printable checklist

One or two days before

• List every mailbox, forwarder, alias and autoresponder
• Save a copy of the current DNS records (MX, SPF, DKIM, DMARC, autodiscover, autoconfig, mail, webmail)
• Find out who uses POP3 and back up their local mail
• Lower the TTL on the MX and related records to 300 seconds
• Create every mailbox on the new host with the same address and a large enough quota
• Recreate forwarders and autoresponders
• Copy existing mail with imapsync, a mail client or a cPanel transfer

Cutover day

• Change the MX records and delete the old ones
• Edit SPF to include the new host, keeping the old one for now
• Publish the new DKIM key
• Check the DMARC policy
• Point autodiscover and autoconfig at the new host
• Point the mail and webmail hostnames at the new server
• Verify with dig MX and a test message, then read the headers

The following days

• Run the final imapsync delta pass, and once more a few days later
• Update mail clients and phones
• Remove the old provider from SPF
• Restore the DMARC policy if you relaxed it
• Check the old mailboxes one last time, then cancel the old account after one to two weeks

Frequently asked questions

Will I lose emails when I change email hosting?

Rarely, if you keep the old account running. While DNS caches expire, some senders still deliver to the old server, which accepts the mail as long as the mailbox exists there. Sending servers that cannot connect at all keep retrying for several days. Mail goes missing when the old account is closed too early, so the old server rejects messages or nobody checks it, or when nobody copies the stragglers across.

How long does an MX record change take to propagate?

As long as the record’s previous TTL, in most cases. If you lowered the MX TTL to 300 seconds a day or two in advance, nearly every resolver picks up the new record within minutes. If you skipped that step, plan for the old TTL, often four hours on cPanel zones and up to 24 hours elsewhere. Changing nameservers is slower, because the delegation TTL at the registry is commonly two days and you cannot lower it.

Do I need to recreate my mailboxes on the new host before switching?

Yes. Create every address on the new host, with the same spelling, before the MX records change. If a sender reaches the new server and the mailbox does not exist yet, the message is rejected and the sender gets a bounce. Along with closing the old account too early, that is how mail really gets refused during a move, and both are avoidable.

How do I copy old emails to the new host?

Over IMAP. For several mailboxes, imapsync copies folders, messages and read flags from one server to the other and can be re-run to pick up only new messages. For one small mailbox, adding both accounts to Thunderbird or Outlook and dragging the folders across works. Between two cPanel hosts, a full account backup or transfer moves the mail along with everything else.

How long should I keep the old email account after switching?

One to two weeks after the MX change. Most mail arrives at the new server within a day, but stray deliveries from badly cached resolvers and slow retry queues trickle in for a few days. Keeping the account also gives you something to compare against if a folder looks short.

Moving your email to GoZen

Every GoZen shared hosting plan runs licensed cPanel with unlimited email accounts, so the steps above apply as written. If you would rather not run imapsync yourself, our free migration service is included with every plan. We move email accounts, forwarders, autoresponders and filters, from another cPanel host or from any provider that supports IMAP, and you check the result before any DNS changes. The step-by-step version of this process for GoZen accounts is in our knowledge base under zero-downtime email migration. If you are setting up email on a domain for the first time, start with custom business email in 10 minutes.