Email Stopped Working After a Website Move

Shopify, Squarespace & Hosting

The website moved successfully. The email did not come along.

datacram.com/fix/email-stopped-working-after-website-move
Likely causes, ranked
Email Stopped Working After a Website Move
MX records not recreated after a nameserver changemost likely
MX records pointing at the old hostcommon
Mail authentication records lostcommon
Mailboxes hosted on the old serverpossible
Fix steps in this guide5
the causes explained below, most likely first
What you’re seeing

The new site is live and working, but incoming email stopped at the moment of the move. Senders get bounce messages, or mail simply never arrives and nobody is told.

What it actually means

Website hosting and email hosting are separate services that happen to share a domain name. The link between them is DNS: one set of records points visitors at your web server, another set — the MX records — points mail at your mail server.

Change nameservers during a migration and DNS control moves wholesale to the new provider, which knows nothing about your email. It creates web records and, unless someone recreates them, your MX records simply cease to exist.

This is the single most damaging mistake in a hosting move, and the one most often discovered late — because nothing errors on your screen. Mail just stops, quietly, while you are admiring the new site.

What usually causes it

Most likely first.

  1. 1

    MX records not recreated after a nameserver change

    The overwhelming majority of cases. DNS control moved and mail routing was not rebuilt.

  2. 2

    MX records pointing at the old host

    Copied across but still referring to a server that no longer hosts your mail.

  3. 3

    Mail authentication records lost

    SPF, DKIM, and DMARC not recreated, so outgoing mail is rejected or spam-filtered even when it sends.

  4. 4

    Mailboxes hosted on the old server

    If email lived on the web host you left, the mailboxes went with it and need migrating, not just repointing.

  5. 5

    Propagation still in progress

    Records are correct but caches still hold the old answer, so mail is briefly split between old and new.

How to fix it

Work through these in order. Take a backup before you change anything.

  1. Step 1Look up your MX records now

    Use an external DNS checker. If nothing is returned, that is your answer and the fix is straightforward.

  2. Step 2Recreate them at the current DNS provider

    Get the exact values from your email provider — Google Workspace, Microsoft 365, or your mail host — and enter them precisely, priorities included.

  3. Step 3Restore SPF, DKIM, and DMARC

    Without these, mail you send is rejected or filed as spam. Recreate all of them, not just MX.

  4. Step 4Confirm where the mailboxes actually live

    If mail was hosted on the old server, repointing records is not enough — the mailboxes themselves must be migrated.

  5. Step 5Test in both directions

    Send to and from the address, and ask someone outside your organization to reply. Then check what was bounced during the outage.

When to stop and call someone

Call someone immediately — this is the most time-sensitive fault on this hub. Mail sent during the outage may bounce permanently rather than queue, so every hour is potentially lost business correspondence you will never see, and unlike a website outage nobody tells you it is happening.

Frequently asked

Because changing nameservers moves all DNS control to the new provider, and it does not know about your email. The MX records that route mail are not recreated automatically, so mail has nowhere to go. Recreating them restores delivery.

DNS records that tell the internet which server handles email for your domain. They are entirely separate from the records pointing at your website, which is why a site can move successfully while email breaks completely.

Some. Many mail servers retry for a day or two and will deliver once records are fixed, but messages that bounced with a permanent failure are gone and the sender was told, not you. That is why speed matters here more than anywhere else.

Record every DNS entry before you change anything, and recreate the mail records at the new provider before switching nameservers. Lower TTLs a day in advance so any mistake can be corrected in minutes rather than hours.

Yes, and it is usually the safer approach. Point the web records at the new host while leaving MX and mail authentication records untouched. Website and email are independent services and do not have to live in the same place.

Free · AI-powered · Emailed to you

See exactly what’s holding your website back.

Get a free audit of your site — speed, SEO, mobile, and security — with the fixes that matter most, delivered as a PDF to your inbox.

Get my free audit
CallGet a quote