How to Change Hosting Without Losing Your Email

Short answer: write down your MX records before you change anything, and recreate them at the new nameservers before you switch. Email breaks during a hosting move because mail routing lives in DNS, and moving nameservers replaces your DNS. Get the records in place first and nothing bounces.

Here is the full sequence.

Why email breaks when you move hosting

Your domain’s nameservers hold every DNS record for it. Two of those matter here:

• A record — where the website lives
• MX records — where email should be delivered

Most people move hosting by pointing their nameservers at the new host. That is the right move for the website. The problem is that it hands control of all your records to the new host — including MX.

The new host does not know you use Google Workspace, Microsoft 365 or anything else. It creates its own default MX records pointing at itself. From that moment, mail for your domain goes to a mailbox on the new server that nobody reads. It does not bounce loudly. It just quietly stops arriving.

The usual way people find out is a customer asking why nobody replied.

Before you touch anything: write down your MX records

Do this while the old setup is still live. Once the nameservers change, the old records may be gone.

# on macOS or Linux
dig MX yourdomain.com +short

# on Windows
nslookup -type=mx yourdomain.com

For Google Workspace you should see something like:

1 smtp.google.com.

Save the exact output. Also check for these, because they affect deliverability and are easy to forget:

dig TXT yourdomain.com +short      # SPF, and often domain verification
dig TXT google._domainkey.yourdomain.com +short   # DKIM

Copy all of it into a note. This is the single step that prevents the problem.

The order that works

1. Set up the site on the new host first. Upload the files, import the database, and test it using the host’s temporary URL or your local hosts file. Do not change DNS yet. The old site stays live and nobody notices.

2. Recreate the mail records at the new host — before switching. In the new host’s DNS zone editor, add your MX records exactly as you saved them, plus the SPF and DKIM TXT records. The zone is not live yet, so this is safe.

3. Lower the TTL a day ahead if you can. TTL is how long the world caches your DNS. If it is set to 24 hours, changes take a day to take effect everywhere. Drop it to 300 seconds the day before, and the switch propagates in minutes instead.

4. Now change the nameservers at your registrar.

5. Verify within the first hour. Send a test message to an address at your domain from an outside account, and check the MX records resolve:

dig MX yourdomain.com +short

If that returns the new host’s own mail server instead of Google’s, fix it immediately — you caught it before customers did.

If you have already switched and mail has stopped

It is recoverable, and usually quickly.

1. Log into the new host’s DNS zone editor
2. Delete any MX record pointing at the host’s own mail server (often mail.yourdomain.com or the server hostname)
3. Add your correct MX records back
4. Re-add SPF and DKIM

Mail that arrived while it was misrouted is likely sitting in a mailbox on the new server. Check the host’s webmail before assuming it is lost.

Senders retry for a while before giving up — typically a couple of days — so messages may still arrive once routing is fixed.

The part nobody mentions

If you use Google Workspace and only fix MX, mail arrives but your outgoing mail from the website — contact form notifications, order confirmations — may start landing in spam. That is SPF and DKIM missing, not MX.

Both live in TXT records, and both need to move with everything else.

Do you have to do it this way?

There is one alternative worth knowing: leave DNS where it is. Rather than moving nameservers, keep them at your current provider and just change the A record to the new server’s IP.

The website moves. Everything else — MX, SPF, DKIM — stays untouched, because you never handed over the zone. It is the lower-risk option and I use it when there is no reason to move DNS at all.

---

Moving hosting and would rather someone else took the risk? Tell me what you are working with — I have done this migration many times, including for clients on Google Workspace where an hour of lost mail is not acceptable.