Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Check live resolution before and after a DNS or transfer change.
Useful when a UK domain transfer depends on TAG or registrar handling.
Check TLD context when transfer and DNS behaviour can vary by namespace.
Email behaves differently from websites, and that difference matters when you change nameservers. A live inbox depends on DNS records such as `MX`, `SPF`, `DKIM`, and `DMARC`. If those records are missing from the new DNS zone, mail can stop arriving or start failing checks. This article focuses on email continuity only. That makes it easier to give clear steps without repeating the website-specific checklist from the companion guide.
Changing nameservers does not move your mailbox. It changes where the domain's DNS records live.
That means email will keep working only if the new DNS zone contains the records your mail provider needs. In most cases, the critical records are:
Depending on the provider, you may also need autodiscover records, verification TXT records, or custom subdomain entries.
Before you switch nameservers, recreate the email records at the new DNS host.
This is the safest approach because it lets you confirm the mail setup before any live traffic moves. If your current DNS host has an export feature, use it. If not, copy the values manually and compare them line by line.
Do not assume that because the website looks fine, email is fine too. The two systems are separate.
Website records can look fine while mail is already broken. Always rebuild and test the mail zone before you point the domain at it.
The exact records depend on your provider, but the following are usually the ones to check carefully:
If your provider has a setup guide, follow it precisely. Small wording or formatting differences in DNS can matter.
| Record | Role | Common mistake |
|---|---|---|
| MX | Routes inbound mail to the correct provider. | Pointing to the wrong host or forgetting a priority value. |
| SPF | Lists which services are allowed to send mail. | Leaving out a sending platform or using multiple conflicting SPF records. |
| DKIM | Signs outgoing mail with a domain key. | Publishing the wrong selector or copying the key incorrectly. |
| DMARC | Tells receivers what to do with failed mail. | Setting a policy before SPF and DKIM are stable. |
Do not delete the old zone as soon as you change nameservers. Email can continue to resolve through cached DNS for a while, and having the old records available gives you a fallback if something was missed.
This matters especially for businesses because incoming mail problems are easy to miss until someone complains. Leaving the old zone available for a transition window makes troubleshooting much easier.
Before changing nameservers:
After changing nameservers:
If your organisation uses multiple mail services, test each one separately. Some domains send through one provider and receive through another.
Most failures come from missing DNS records rather than from the nameserver update itself.
Typical problems include:
If email stops working, check the DNS zone first. The mailbox may be fine, but the domain can no longer point to it correctly.
Restore the previous DNS zone or import the missing mail records exactly as they were.
Rebuild the zone from memory and keep chasing intermittent failures across different mail providers.
Export the old zone and test the new one before the switch, not after the inbox complaints start.
Mail providers often use their own setup patterns. Some want a specific MX set, some rely on extra TXT records, and some require a unique record for webmail or autodiscovery.
That is why there is no universal one-size-fits-all email checklist. The structure of the move is the same, but the exact record values must come from your provider's instructions.
If email continuity is the priority, do not combine the nameserver change with other risky changes unless you must.
Avoid:
The safer the scope, the easier it is to recover if something is missed.
Once mail is flowing through the new DNS zone, review the setup one more time.
Confirm:
If you use email for a business, it is worth documenting the final DNS values so the next change is easier.
Send a test message between different providers if you can. A setup that works in one mailbox can still fail in another because of SPF, DKIM, or DMARC alignment.
You can change nameservers without breaking email if the new DNS zone already contains every record your mail system depends on and you keep the old zone available long enough to catch mistakes.
The key idea is simple: copy the mail records first, switch second, and verify immediately after.