Email stopped working after a website move? How to fix it

If your email stopped working after a website move or a nameserver change, your mailboxes are almost certainly still there. What broke is DNS. The new DNS provider (often Cloudflare, Hostinger or a fresh GoDaddy account) is missing your MX, SPF, DKIM or autodiscover records, or one of them now points at the wrong server. Recreate those records exactly as your mail provider lists them and incoming mail usually starts flowing again within a few hours, with full propagation in 24 to 48 hours.

SiteGround's guide to this problem says it plainly: email records "do not transfer automatically" when you change nameservers, and your existing messages live on the mail server, not in DNS. So you're repairing something, not recovering lost data. The one exception is if you also cancelled the hosting plan that held your mailboxes. I cover that further down.

Why is email not working after a website move?

Your website and your email are two separate services that happen to share a domain. DNS is the address book that tells the rest of the internet where each one lives. When you point the domain at new nameservers (Cloudflare, Hostinger, a new GoDaddy account), you hand that whole address book to a new provider. Anything that wasn't copied across stops existing. As SiteGround explains, changing nameservers moves your entire DNS zone to the new provider, not just one setting.

Email records are the ones that get forgotten, because nobody looks at them until mail stops. It usually breaks in one of five ways:

• The MX records were never recreated at the new DNS provider, so incoming mail has nowhere to go.
• A mail hostname now points at the new web server. If mail.yourdomain.com was a CNAME to the root domain, moving the website moved "mail" with it.
• Cloudflare is proxying a mail record (the orange cloud), so mail servers connect to Cloudflare instead of your mail host.
• SPF, DKIM or DMARC are missing or wrong. Mail still arrives, but what you send bounces or lands in spam.
• The mailboxes lived on the old host and that hosting plan has been cancelled.

What should you check first today?

Work through it in this order: where your DNS lives now, who hosts your mailboxes, then the MX records, mail hostnames, Cloudflare proxy status, and finally SPF, DKIM and DMARC. Each fix takes minutes. Most of the waiting afterwards is DNS caching, not you.

1. 1

   Confirm where your DNS lives now

   Look up your domain's nameservers (any WHOIS or DNS lookup tool shows them) and only edit records at that provider. Once the nameservers have moved, editing the old registrar's zone does nothing.

2. 2

   Find who hosts your mailboxes

   This could be Google Workspace, Microsoft 365, Zoho, or email bundled with your old cPanel host. Their admin panel lists the exact records you need.

3. 3

   Restore the MX records

   Copy the MX values and priorities from your mail provider's setup page, not from memory. Delete any leftover MX records that point at the old web host.

4. 4

   Fix mail hostnames and the proxy

   Make sure mail, autodiscover and any IMAP or SMTP hostnames point at the mail provider, and set them to DNS only in Cloudflare.

5. 5

   Restore SPF, DKIM and DMARC

   Publish one SPF TXT record, the DKIM record from your mail provider and a DMARC record at _dmarc. Then send a test to a Gmail and an Outlook address.

6. 6

   Check from outside

   Query the records against public resolvers such as 1.1.1.1 and 8.8.8.8, and read the headers of a test email for spf=pass, dkim=pass and dmarc=pass.

If you've got the old zone file or even a screenshot of the old DNS page, that's your checklist. If the new provider imported records automatically, don't trust the import. Compare it line by line.

Which DNS records does business email need?

Six kinds: MX, A or CNAME records for the mail hostnames, autodiscover, SPF, DKIM and DMARC. The table shows what each one does and what you'll notice when it's missing.

For Google Workspace, new setups use a single MX record, smtp.google.com at priority 1, while older domains can keep Google's legacy five-record set, as Google's MX setup guide explains. Don't mix the two in a panic. Use whatever the Google Workspace Admin console shows for your domain. For Microsoft 365, the usual extras are an autodiscover CNAME to autodiscover.outlook.com and an SPF include for spf.protection.outlook.com, plus the MX and DKIM values in your Microsoft 365 admin centre.

Is Cloudflare's orange cloud breaking your email?

Quite often, yes. Cloudflare's proxy (the orange cloud) only handles web traffic, so any proxied mail record breaks email. Cloudflare's own documentation says "MX records cannot be proxied", and that an A or AAAA record used only for email, such as mail.example.com, should be set to DNS only.

The typical mistake is a mail hostname left orange after a Cloudflare import, or a mail CNAME pointing at the proxied root domain. Switch each mail-related record to the grey cloud and check that "mail" points at the mail server's real IP, not the new web host.

Why can you receive email but not send it, or land in spam?

If incoming mail works but what you send bounces or goes to spam, the problem is authentication: SPF, DKIM or DMARC. There are four usual causes.

• Two SPF records. A domain can have only one SPF TXT record. A second one causes a PermError and SPF fails completely. New hosts sometimes add their own default SPF next to yours, so merge them into one.
• Too many lookups. SPF also fails if the check needs more than 10 DNS lookups. You hit that by adding an include for every tool that sends email on your behalf.
• Missing DKIM. The DKIM key is a record your mail provider generates. If it didn't come across, publish it again, then turn signing back on in the admin panel if needed.
• DMARC set to reject. With p=reject and SPF or DKIM failing, receivers are told to throw your mail away. Drop to p=none while you fix things, then tighten it once tests pass.

This matters more than it did a couple of years ago. Google now requires SPF, DKIM and DMARC from anyone sending more than 5,000 emails a day to Gmail, and Yahoo applies similar requirements to bulk senders. Even if you send far less, set up all three. It costs nothing.

One case catches a lot of WordPress sites: contact form notifications stop arriving after the move. The new web server is now the one sending those emails, and it isn't in your SPF record. Don't keep adding hosts to SPF. Send WordPress mail through your real mail provider with an SMTP plugin instead. On the Taxocity site I built, every lead is also saved to a Google Sheet, so an enquiry still gets captured even if a notification email fails.

Why does Outlook keep asking for a password?

Almost always because the autodiscover record is missing or points at the wrong server. Outlook looks up autodiscover.yourdomain.com to find your mailbox settings. If that record is gone, or now points at your new web host, Outlook gets a certificate error or a login prompt it can never get past. Recreate the autodiscover CNAME your mail provider specifies, set it to DNS only in Cloudflare, then restart Outlook.

How long until email works again?

Once the records are right, receiving usually recovers within a few hours, and full propagation can take 24 to 48 hours. That range depends on your TTL, because resolvers hold on to cached answers until the TTL runs out. Mail sent to you during the outage isn't necessarily lost either. Sending servers normally queue messages and retry for a while before giving up, so a lot of it turns up late rather than never.

What if your email lived on the old host?

Then contact the old host today. If the hosting plan was cancelled, the mail may only be recoverable from their backups. Plenty of small business inboxes run on email bundled with Hostinger, GoDaddy or another cPanel host. Move the website, cancel the plan, and the MX records can end up pointing at a server that no longer holds your mailboxes. Some hosts keep data for a short grace period, so speed matters. After that, set up mail somewhere stable, migrate what you can over IMAP and point MX there.

Microsoft 365 bought through GoDaddy can trip you up in a similar way, so check every record against what your Microsoft 365 admin centre lists. And if you can't log in to the registrar or DNS at all because a previous developer set them up under their own account, start with how to take back your WordPress site when a developer disappears.

How do you stop email breaking on the next website move?

Sort out email before you touch the website. When I handled hosting and DNS migrations across Hostinger and GoDaddy for Aura Clips' UK hospitality and e-commerce clients, I sorted email records before switching nameservers. For a venue or a restaurant, the inbox is where bookings land, so a broken MX record costs real money. This is the order I follow:

1. Export or screenshot the full zone before touching anything, including TXT, CNAME and SRV records you don't recognise.
2. Write down who hosts email and keep their setup page open.
3. Lower TTLs a day or two ahead so any mistake can be corrected quickly.
4. Recreate every record at the new provider first, then switch nameservers.
5. Set every mail record to DNS only in Cloudflare.
6. Test straight after the switch. Send to and from Gmail and Outlook, and check the authentication results in the headers.
7. Keep the old host live until email and the website are both verified.

The website side of the same move is in how to move a WordPress site to a new host without downtime.

What should you ask a developer before a DNS move?

Two questions matter most: who hosts your email, and will they export the current DNS zone and recreate the email records before switching nameservers? If a developer can't answer those clearly, your email is at risk. The full list I'd want answered:

• Who hosts our email, and will you recreate its records before switching nameservers?
• Will you export the current DNS zone and share a copy with us?
• Which records will be proxied in Cloudflare, and which will stay DNS only?
• How will you test sending, receiving and authentication after the switch?
• Are the registrar, DNS and hosting accounts in our name, not yours?
• What's the rollback plan if something breaks?

These checks belong in any ongoing maintenance retainer too.

Need it fixed today?

If your inbox is down right now, send me your domain and the name of your mail provider. I'll check the live records, tell you which ones are missing or wrong, and fix them with you. For planned moves, my hosting migrations, DNS and maintenance service handles the website and email together, with no lost email. Book a 20-minute call or get in touch.