Domain Email Stopped Working After Website Migration

If your email died right after moving your website to a new host, the cause is almost always your MX records: either they got dropped during the move, they still point at your old mail server, or the new host silently created its own email setup and overwrote what you had. Website files and DNS records live in different systems, so migrating one doesn't automatically carry the other with it. Fix the MX records first; everything else on this page is either how to confirm that's the problem or what to check if MX turns out to be fine.

Here's the part that trips people up: this usually isn't a clean outage with an error message. Mail can keep “half-working” for a day or two because other mail servers cache your old MX record and keep delivering to your old server, which may or may not still be running. That's why “it broke right after migration” often actually means “it broke 6-30 hours after migration,” and why the fix looks like it didn't work even after you've corrected the records.

Why a website move takes email down with it

A domain has three things that can move independently, and migrations usually only touch one of them:

• Nameservers -  which company answers DNS queries for your domain
• DNS zone records - the actual MX, A, TXT, and CNAME entries within that nameserver's system
• Hosting account - where your website files and, often, your mailboxes physically live

Most “easy migration” tools (cPanel-to-cPanel transfers, Softaculous, a host's one-click WordPress mover) copy website files and databases. They frequently do not touch DNS at all, because DNS is a nameserver-level function, not something bundled into a hosting account backup. So one of two things happens:

1. You (or your host) changed nameservers to point at the new host, and the new host's default DNS zone doesn't include your old MX records, because it never saw them. It just writes generic starter records for a new account.
2. You kept your DNS with your original provider (say, your domain registrar or Cloudflare) but changed the A record to point your website at the new server. If you also let a “quick setup” wizard touch MX at the same time, it can quietly rewrite mail routing to match the new host's own mail service, even if you never intended to use it.

Either way, the result looks identical from the inbox: mail stops arriving, or it arrives at an inbox you can no longer log into.

Confirm it's actually DNS before you touch anything else

Don't start resetting passwords or calling your email provider yet. Two minutes of lookup work will tell you exactly what's wrong.

Check your live MX records. Run this from a terminal, or use a free tool like MXToolbox:

dig MX yourdomain.com +short

Compare what comes back to what it should be. If nothing returns, or it returns your new web host's mail servers instead of your actual mail provider's servers, you've found it.

Check for a bounce message pattern. If senders are getting NDRs (non-delivery reports), read the actual bounce text rather than skimming it. “550 5.1.1 recipient rejected” means the receiving server exists and is refusing the address (a mailbox problem, not DNS). A timeout, “Host not found,” or the message routing to an unfamiliar server name in the bounce header means DNS is sending mail to the wrong place, or nowhere.

Check whether it's inbound, outbound, or both. Inbound failure (nothing arrives) is a symptom of MX pointing at the wrong place. Outbound failure (your sent mail bounces or lands in recipients' spam) is a different and easily-missed problem: your new hosting server has a different outbound IP address than your old one, and if your SPF record wasn't updated to authorize that IP, receiving mail servers can reject or spam-flag everything you send under RFC 7208's SPF policy. Both problems can hit at once and get lumped together as “email is broken,” but they need different fixes.

The specific causes, ranked by how often they're the culprit

The TTL issue deserves a specific number, because “just wait for propagation” is the advice everyone gives without saying how long. A DNS record's TTL, set in seconds, tells other servers how long they're allowed to cache it before checking again. A record with a 14,400-second (4-hour) TTL, which is a common default at registrars like GoDaddy and Namecheap, can keep routing mail to your old server for up to 4 hours after you fix it, and up to 4 hours of stale caching by any resolver that queried right before your change. Records with a 24-hour (86,400-second) TTL, still common on older cPanel-managed DNS zones, can take a full day to fully clear. This is why support forums repeat “up to 48 hours” as a blanket answer: it's a safe upper bound, not a precise one, and depends entirely on what TTL was set on the record before you changed it.

What your MX records should actually look like

If you're re-entering MX records from scratch because they got wiped, match them exactly to your provider's published values, not to a template someone posted in a forum three years ago. A wrong priority number or a typo'd hostname is the second most common self-inflicted cause of this whole problem.

Google consolidated its old five-record MX setup (aspmx.l.google.com plus four alt backups) down to the single smtp.google.com record for all Workspace domains as of their 2023 migration; if you're copying an old guide, you'll add four unnecessary and now-defunct records. Microsoft 365's MX hostname is unique per tenant and always follows the yourdomain-com.mail.protection.outlook.com pattern (dots in your domain become hyphens), which you can pull directly from the Microsoft 365 admin center under Setup > Domains rather than guessing.

Fixing it, in order

1. Re-add or correct the MX record at whichever DNS provider currently controls your domain's authoritative nameservers (check with dig NS yourdomain.com if you're not sure who that is anymore).

2. Update your SPF TXT record to include the new server's sending IP or the include mechanism your mail provider gives you (Google Workspace uses include:_spf.google.com, Microsoft 365 uses include:spf.protection.outlook.com). Don't run more than one SPF TXT record per domain; multiple records is itself an RFC 7208 violation that causes a permanent SPF fail.

3. Re-add DKIM, which is almost never bundled into a "restore my MX records" fix because it lives as a separate TXT or CNAME record under a selector subdomain (something like google._domainkey.yourdomain.com). Pull the exact value fresh from your mail provider's admin panel rather than reusing an old one, since DKIM keys sometimes rotate during provider-side changes.

4. Leave the old server running if you can, for at least 48 hours. Killing the old mailbox the moment you flip DNS means any mail still routed there by a slow-to-expire cache bounces hard instead of just arriving late.

What to change before your next migration, not after

The single highest-leverage move is lowering your MX and SPF TTLs to something like 300 seconds (5 minutes) a day or two before you migrate anything. That shrinks your entire propagation exposure window from potentially 24+ hours down to single-digit minutes, and it costs nothing. Set it back to a normal value (3600 or higher) once the migration is confirmed stable, since a permanently tiny TTL adds unnecessary query load to your DNS provider.

The second move is exporting your full DNS zone file before you touch nameservers, not after something breaks. Most registrars and DNS hosts (Cloudflare, DNS Made Easy, even GoDaddy's DNS manager) have a one-click zone export. Five minutes of prevention here is the difference between a copy-paste fix and rebuilding your MX, SPF, and DKIM records from memory while your inbox is dead.

If you've gone through this checklist and mail is still not arriving 48 hours after correcting the MX record with a low TTL confirmed via dig, the problem has moved past DNS: check whether the mailbox itself still exists on the new server, and whether your mail provider's own status page is reporting an incident.

Related Guides

SPF, DKIM & DMARC Setup for Business Email: The Complete 2026 Guide - a deeper walkthrough of the authentication records this article touches on, including DNS lookup limits and how to roll out DMARC without breaking mail flow.

How to Set Up Email on a GoDaddy Domain: The Complete Guide - useful if your migration involves a GoDaddy-registered domain, covering mailbox hosting choices, DNS propagation timing, and common SMTP authentication errors.