Email stopped working after a website move: how to avoid it and fix it

Email stops after a website move when the move changes who holds your domain's DNS records and the new holder does not have your mail records. The website and email share a domain name but run on different services, and the records that route mail sit in the same place as the records that point to the site. The fix is to list every record before the move, copy the mail ones, and send a test email in both directions once the new name servers are live.

Why a website move can touch email

A domain's DNS records say where things go. One record says the website is at a certain address. Others say which company receives mail for the domain. If your name servers are changed, the new name servers answer every question about the domain. Anything the new zone does not contain simply stops resolving.

The usual causes are an incomplete copy and an old record left in the wrong place. A mail record is easy to lose, because nothing on the website uses it. Nobody notices until a client says they emailed last week and never heard back.

The point is to treat the move as a copy job. Here are three we did recently, and what the copy included.

Example 1: Microsoft 365 mail

On 1 October we moved the DNS for a parts retailer's domain to a new Cloudflare account. The business runs its email on Microsoft 365, and the website is hosted separately on Vercel.

We copied all 15 records. That covered the mail exchange records, the autodiscover records Outlook uses to set up an account, the enterprise enrolment records, two DKIM selectors, the SPF and DMARC records, a Google DKIM record, and the verification records for Google and Microsoft. We then compared the old and new zones by their API output, record by record: type, name, content, TTL and priority. They matched exactly.

The domain is registered at GoDaddy, in the owner's account, so the change of name servers was made there by the owner. The new zone went active about three minutes after the registry showed the new name servers. The sites returned 200 and the Microsoft 365 records were intact.

All the records were set to grey cloud, meaning DNS only, with no proxying. That matters for the website records, and it is irrelevant for mail, which is never proxied.

Example 2: Google Workspace mail and two records we dropped

When we rebuilt a workwear supplier's site on 9 October, the business used Google Workspace for email, with leads going to a Workspace address. The old host had died, so the DNS was moved at the same time.

We copied the Google MX records, SPF, DKIM and DMARC into the new zone, plus the records for an outbound email provider the business had also used. Two things we left behind on purpose were a Mailgun set of records and a Shopify record for a shop address. We judged both redundant, and a dead record is a loose end.

That is the other half of the job. Copying everything is the safe default, and dropping a record is a decision somebody makes and writes down. A record you keep forever because you are not sure what it does is a small risk. A record you remove without checking can silence a tool nobody mentioned.

Example 3: Google mail kept, no DKIM to lose

When a builder's site moved off Wix, the imported records included five Google mail records, an SPF record and two verification records. We kept all of them and removed only the three website address records and the www alias that pointed at Wix. There was no DKIM or DMARC record on the live domain, so there was nothing of that kind to lose. A domain that never had DKIM is a weakness of its own, which our post on why contact form emails land in spam explains. The full sequence is in what a move off Wix looks like.

A fourth case: forwarding that needed a click

On one site, the plan was to forward mail using a Cloudflare feature called Email Routing. That feature sends mail to a destination address, and the destination has to confirm it will accept it. On the new account the destination address had not been verified. We held that site back until it was, so mail would not be pointed at a destination that had not agreed to accept it.

The lesson applies beyond Cloudflare. Some email arrangements have a confirmation step that sits in someone's inbox, and the move waits on it.

What goes wrong in practice

• A record missing in the copy. Fix: add it to the new zone. Mail resumes when caches expire.
• Old name servers still answering. Some networks use the old answer for hours. Two people in the same office can see different results.
• Your own tools mislead you. On our network, a transparent resolver intercepted queries to the new name servers, so a lookup straight to them returned answers without the authoritative flag. We relied on a comparison of the records through the API, and on public DNS-over-HTTPS lookups, and not on a command line query from the office.
• A separate domain for email. When pagecog.com.au went dark in a registry hold, email on pagecog.com continued working, because it used a different domain. If your mail runs on a different domain from the website, a website problem cannot touch it. For how a domain lapse spreads, see what happens when a domain expires.

A checklist before changing name servers

1. Export every DNS record from the current provider. Screenshots are fine.
2. Mark each as website, mail, verification or unknown. Ask about the unknown ones.
3. Copy the mail and verification records into the new zone first.
4. Compare the old and new records before you switch.
5. Change the name servers at the registrar, which is often a different company from your website builder. Our post on who actually owns your website explains the accounts involved.
6. Send a test email in both directions, immediately and the next morning.
7. Keep the old records for a week in case a tool you forgot about complains.

If a move has already gone wrong, the first step is a lookup of your domain's MX records using the new name servers. If it comes back empty, copy the records from the old provider's export and the mail returns once caches refresh. Mail sent while the records were missing may bounce, or may be held by the sender and retried for a few days. We do not know which in advance.

How we handle it

On our base plan there is no upfront build fee, and the DNS and email check is part of putting a site live, which the web design service page describes. If you are planning a move and want someone to run this checklist, get started here.