Changing web hosts only affects your email in two situations: your mailboxes live on the old hosting account, or your DNS records get lost when the domain is pointed somewhere new. If your email is with Microsoft 365 or Google Workspace and the records are copied across, nothing changes. Either way, a planned move shouldn’t lose a single message.
Key takeaways
- Your domain’s MX record shows where your email actually lives. Check it before anything else.
- Email on the old host must be moved, and the old account kept open until it is.
- Moving nameservers without copying every DNS record is the most common way email breaks.
- Sending servers keep retrying for days, so a short gap usually delays mail rather than losing it.
Where does my email actually live?
Your website and your email are separate services that happen to share a domain name. Your domain’s DNS holds an MX record, which tells the world’s mail servers where to deliver mail for your address.
Most small businesses fall into one of three setups:
- Microsoft 365 or Google Workspace. Mail sits with Microsoft or Google. Your web host never touches it.
- Mailboxes on your web hosting. Common with cPanel hosting. Your email and website share one account, so moving one affects the other.
- Email or forwarding from your domain registrar. Mail is tied to where your DNS is managed.
How do I check?
Look up your MX record with a free tool such as Google’s Dig tool. Type your domain and choose MX. A result ending in mail.protection.outlook.com means Microsoft 365. One showing smtp.google.com or aspmx.l.google.com means Google Workspace (Google). Something like mail.yourbusiness.com.au, or your host’s server name, usually means your hosting account.
What are the two ways email gets lost in a host move?
1. The old account closes before the mail moves
If your mailboxes are on the old hosting, they’re deleted when that account is cancelled or expires. Everything stored on the server goes with them: inbox, sent items and folders. If you use IMAP, which keeps mail on the server, that’s usually all of it.
The same thing happens in reverse if the MX record is switched before the new mailboxes exist. Mail arrives at the new service, finds no mailbox and bounces back to the sender.
How to avoid it: create every mailbox and alias first, copy the old mail across, then switch the MX record. Keep the old account open for about two weeks, and check it for stragglers.
2. The nameservers move, but the records don’t
This one catches people whose email was never on the web host. When a new host asks you to point your domain at its nameservers, your DNS records start being read from the new provider. If the MX, SPF, DKIM and verification records weren’t recreated there first, mail stops arriving or starts landing in spam.
How to avoid it: export or screenshot the full DNS zone before changing anything, recreate every record at the new provider, and compare the two. Microsoft’s setup guide also says to remove MX records that point to a previous provider, so mail goes only to the new one (Microsoft Learn). Our domain and DNS management page explains how we keep these records in one place.
What happens to mail sent during the switch?
Usually, nothing bad. A sending server must queue a message it can’t deliver and retry it. The retry interval “SHOULD be at least 30 minutes”, and senders generally keep trying for at least 4–5 days before giving up (RFC 5321). A short gap delays mail. It doesn’t lose it.
The real risk is mail delivered to the old server after you’ve stopped looking. DNS changes take time to spread, and Google allows up to 72 hours. For those few days, some mail may still land in the old mailboxes. That’s why the old account stays open.
How do I change hosts and keep email working?
- Find where email lives. Check the MX record and list every address, alias and forwarder.
- Copy the DNS zone. Save every record, including TXT records for SPF, DKIM, DMARC and services like Google Search Console.
- Set up the destination. Create the records, and the mailboxes if email is moving, before switching anything.
- Copy old mail. If mailboxes are moving, migrate the stored messages, not just the accounts.
- Switch, then test. Send mail to and from each address, including from an outside account.
- Wait before cancelling. Keep the old hosting for about two weeks, and check it for late arrivals.
If you’re doing the website side yourself, our guide to DIY website migration covers what plugins move and what they leave behind. For the Google side of a move, see our article on website migration SEO.
Should I move my email off my web hosting while I’m at it?
It’s worth considering. With email on Microsoft 365 or Google Workspace, future website moves don’t touch your mail at all. If your needs are simple, keeping email with your hosting is fine, as long as you know it’s there.
Our free website migration is included with our hosting plans, and our servers run in Australian data centres. If you’re curious about the building itself, our explainer on NEXTDC covers it.
Frequently asked questions
Will I lose old emails when I change hosts?
Only if your mailboxes are on the old hosting and the account is closed before the messages are copied. Email with Microsoft 365 or Google Workspace stays where it is. If your mail is on the old host, copy it across and keep the old account open until you’ve checked everything arrived.
Do I need to change my email settings in Outlook or on my phone?
Only if your email moves. If the mailboxes move to a new server, the incoming and outgoing server names and passwords may change, so each device needs updating. If your email is with Microsoft or Google and stays there, your devices don’t need touching.
Can I change web hosts and keep my email with the old host?
Sometimes. If the old host will keep an email-only account, point the website records to the new host and leave the MX record alone. Many hosts tie email to a hosting plan, though, so check that the old account will stay active before you cancel anything.
Why is my email going to spam after moving hosts?
Usually because SPF, DKIM or DMARC records were missed when DNS moved, or because the website’s contact forms now send from a new server that isn’t listed in your SPF record. Recreate the missing records and add the new server to SPF.
Sources
- Dig (DNS lookup), Google Admin Toolbox
- Set up MX records for Google Workspace, Google
- Connect your domain by adding DNS records, Microsoft Learn, 2026
- RFC 5321: Simple Mail Transfer Protocol, IETF, October 2008