Migrating your site to new hosting can silently kill your domain email. It doesn’t have to. Your email lives in DNS, not your files, and that’s the whole trick.
Here is the nightmare version. You move your WordPress site to faster, cheaper hosting, everything looks great, and a day later you notice you have stopped getting email at your own domain. Password resets, client messages, plugin license confirmations, the code your bank texts, all of it routed to an inbox that quietly went dark. It happens more than people admit, and it is entirely avoidable, because your email does not live in the same place as your website. Once you understand that, the whole migration gets a lot less scary.
In Brief
Yes, you can move the site and keep the email. Your website, meaning the files and database, and your email, meaning the mailboxes routed by your domain’s MX records, are separate systems. Migrating the site only breaks email if you also change the MX records or point your nameservers at the new host. So you have two safe options: leave your email where it is and update only the website’s DNS records, or deliberately move the mailboxes to the new host or a dedicated email provider first. Either way, lower your DNS TTL ahead of time, keep the old hosting running during the overlap, and test before you cancel anything.
Why migrating a site can kill your email
A hosting account usually holds two separate things: your website and, if you use host-based mailboxes, your email. The website is served based on your domain’s A record, while your email is delivered based on your MX records. Moving WordPress itself, the files and the database, does nothing to your email. The trouble starts when you point your nameservers at the new host to finish the move. That loads the new host’s DNS zone, which often has no idea your mail lives elsewhere, so it overwrites or drops your MX records and your inbox goes silent. That is the exact mistake behind most “the migration ate my email” horror stories.
First, find out where your email actually lives
Before you touch anything, look up your current MX records to see which server actually handles your mail. While you are in the DNS zone, export or screenshot your MX, SPF, DKIM, and DMARC records, because those four are what keep your mail flowing and passing authentication. This five-minute step is your safety net: if something goes wrong, you can put the records back exactly as they were. Skipping it is how a reversible mistake becomes a scramble.
Two safe paths through the move
Path A: keep your email exactly where it is. If your mail is fine and you just want faster website hosting, do not move the mailboxes at all. Manage your DNS at your registrar, migrate the site to the new host, and then change only the website records, the A record and any CNAMEs, to point at the new server. Leave the MX records untouched. Your email never moves, never blinks, and never notices the site went anywhere.
Path B: move your email too, on purpose. If you are also leaving host-based email behind, do it deliberately and in order. Set up the new mailboxes first, whether on the new host or a dedicated provider like Google Workspace or Zoho, then sync your existing messages over IMAP so nothing is lost. Add your SPF, DKIM, and DMARC records on the new side, and only then switch the MX records. Keep both systems live during the cutover, and after the switch run one more sync to catch any mail that arrived mid-move.
The pre-migration checklist
Work this in order and your inbox survives the move.
- Inventory what depends on that email. Your domain registrar login, hosting account, plugin and theme licenses, two-factor codes, and client contacts likely all route there. Know the stakes before you start.
- Lower your MX TTL. Drop it to 300 seconds at least a day or two before migrating, so any DNS change propagates in minutes instead of hours.
- Export your DNS records. Save your MX, SPF, DKIM, and DMARC values so you can restore them exactly.
- Back up your mailboxes. Pull an IMAP copy of your email even if you plan to keep it in place. A backup you never need beats the alternative.
- Migrate the site and test it on a temporary URL. Move the files and database, and confirm the site works on the new host before any DNS points to it.
- Update only the website DNS. Change the A and CNAME records to the new host and leave MX alone, unless you are intentionally moving email.
- If moving email, cut over carefully. Create the mailboxes, IMAP-sync the messages, set the authentication records, then switch MX and re-sync once more.
- Keep the old hosting until you are sure. Confirm both the site and email work end to end for a few days before you cancel the old account.
Frequently Asked Questions
Does migrating a WordPress site delete my email?
Not by itself. Moving the files and database does not touch email. Email only breaks if you change your MX records or switch nameservers to a new host that overwrites them.
How do I move my site but keep my current email?
Migrate the site, then update only the website’s A and CNAME records to the new host and leave the MX records pointing at your existing mail. The email stays exactly where it is.
What happens to my email if I change nameservers?
The new host’s DNS zone takes over, and if it does not include your existing MX records, your mail delivery can stop. Always recreate your MX, SPF, DKIM, and DMARC records on any DNS you switch to.
How do I move host email without losing messages?
Set up the new mailboxes first, sync your old messages over IMAP, add your authentication records, then switch the MX records. Run one final sync afterward to capture anything delivered during the change.
How long does DNS take to update after I switch?
Anywhere from a few minutes to 24 to 48 hours, depending on your TTL. Lowering the MX TTL to 300 seconds a day or two ahead makes the switch propagate almost immediately.
Should I keep the old hosting during migration?
Yes. Keep it active until the site and email both work on the new setup. Canceling too early is the fastest way to lose messages that are still routing to the old server.
Closing Thoughts
A site migration feels risky mostly because email seems to ride along with it, and it does not. Separate the two in your head, protect your MX records, and the move becomes routine. Find out where your mail lives, back up the records, migrate the site, and change only the website’s DNS unless you truly mean to move the mailboxes too. Do that and you get the faster hosting without the silent inbox. For more WordPress upkeep, see how to fix a WordPress updating-failed error and how to vet a plugin before you install it.