Email Stopped Working After Changing Nameservers? How to Get It Back

You moved your website to a new host, or pointed your domain at a new service, and the website works. Then the phone calls start: nobody has received email since yesterday. Clients get bounces. Or mail arrives from some senders but not others, Outlook keeps asking for a password, and your contact form messages have stopped reaching the office. Your email provider has not changed, so why did email break?

This happens so often that many hosting companies keep a help article for it. The cause is nearly always the same: changing nameservers moves the whole DNS zone for your domain, and the email records were left behind. The good news is that nothing has been deleted at your email provider. Your mailboxes and old messages are safe. You need to put the right DNS records back, and check whether any mail went astray while they were missing. This guide is for site owners and designers who have just done a move and need email back today.

What is happening

Your domain’s DNS records live in a zone. The nameservers set at your domain registrar decide which company’s copy of the zone the whole internet reads. When you change nameservers, you are not moving a few records: you are telling the world to stop reading the old zone and read a completely new one.

The new provider builds that new zone. Some import what they can find, some start from a template, and almost all add their own defaults. The result typically looks like this.

Record	Old zone (worked)	New zone (broken)	Effect
MX	Points at your mail provider (Google, Microsoft, Zoho, your old host)	Missing, or replaced by the new host’s own mail.example.com	Incoming mail goes nowhere, or to a mailbox on the new web server
SPF (TXT)	Lists your mail provider and website	Missing, or the new host’s default only	Your outgoing mail fails SPF and lands in spam or is rejected
DKIM (TXT or CNAME at SELECTOR._domainkey)	Your provider’s key	Missing; importers almost never find these because they sit on names nobody guesses	DKIM fails; with DMARC enforcing, mail is rejected
DMARC (TXT at _dmarc)	Your policy	Missing	Less protection against spoofing; some receivers trust you less
Autodiscover (CNAME or SRV)	Points at your mail provider	Missing, or pointing at the new host	Outlook and phones cannot find settings and keep asking for a password
Verification TXT records	google-site-verification, MS=ms... and others	Missing	Provider admin consoles show the domain as unverified or unhealthy

A website move without a nameserver change (just changing the A record at your existing DNS provider) normally does not touch email. If that is what you did and email broke, the new host may still be involved through local mail delivery, covered in Step 6.

Where did the missing mail go?

That depends on what the new zone said while it was wrong.

• MX pointed at the new host and the new host accepted mail for your domain: messages were delivered into mailboxes on the new web server, or rejected with “No such user here” if no mailbox existed. Delivered mail is not lost; it is sitting there. Rejected mail bounced back to the sender.
• No MX record at all: under the SMTP standard (RFC 5321), a sender that finds no MX record tries the domain’s A record instead, which is now your web server. If that server runs a mail service, the same as above applies. If not, senders get connection failures.
• Temporary failures (no answer, connection refused): sending servers queue the message and retry. RFC 5321 says the give-up time generally needs to be at least four to five days, and most large providers retry for a day or more. Fix the records quickly and much of this mail will still arrive.
• Permanent failures (a 5xx reply such as 550 5.1.1): the sender got a bounce straight away. Those messages need to be sent again.

Before you start

You need login access to your domain registrar (to see the nameservers), the new DNS provider (to add records) and, if possible, the old one. You also need to know who actually hosts your email. The commands below use dig, which runs in Terminal on your own computer on macOS and Linux. On Windows, install the BIND tools or use WSL; PowerShell’s Resolve-DnsName example.com -Type MX -Server NAMESERVER does the same job. If you cannot run commands, the DNS lookup tool shows the public records in your browser. The dig cheat sheet explains every flag.

Replace example.com with your domain throughout.

Step 1: Confirm the nameserver change is the cause

dig NS example.com +short
dig example.com MX +short

NS asks which nameservers are in charge of the domain; +short prints only the answers. The first command should show the new provider’s nameservers, for example ns1.newhost.net.. The second shows where the world now sends your mail. Compare it with what your mail provider expects:

Provider	MX should look like
Google Workspace	1 smtp.google.com. (older setups: aspmx.l.google.com and the alt servers)
Microsoft 365	0 example-com.mail.protection.outlook.com. or a value ending mx.microsoft.
Zoho Mail	mx.zoho.com, mx2.zoho.com, mx3.zoho.com (regional variants such as zoho.eu)
Fastmail	in1-smtp.messagingengine.com and in2-smtp.messagingengine.com
Mail at the old web host	Usually mail.example.com pointing at the old server’s IP

Always check the exact values in your provider’s admin console; the table is for recognizing them. If the MX answer names the new host, or is empty, you have found the problem.

Step 2: Get the old records back

The fastest source is the old DNS provider itself. When you change nameservers at the registrar, the old provider usually keeps serving the old zone from its own nameservers until the account or zone is deleted. You can ask those servers directly, bypassing the registrar.

Find the old nameservers

Look in your old host’s welcome email or control panel, your registrar’s change history, or a screenshot from before. They often look like ns1.oldhost.com. Below, OLD_NS and NEW_NS stand for one old and one new nameserver name.

Query the old zone directly

dig @OLD_NS example.com MX +short
dig @OLD_NS example.com TXT +short
dig @OLD_NS _dmarc.example.com TXT +short
dig @OLD_NS autodiscover.example.com +short
dig @OLD_NS _autodiscover._tcp.example.com SRV +short

The @OLD_NS part sends the question straight to that server rather than through your normal resolver, so you see what the old zone contains right now. The TXT query returns SPF and verification records. Good output is the records you remember, such as your Google or Microsoft MX values and a "v=spf1 ... line. If every query times out or returns nothing, the old zone has been removed; go to “If the old zone is gone” below.

Find the DKIM records

DKIM records sit at SELECTOR._domainkey.example.com, and you can only look them up if you know the selector. Common ones:

Provider	Selector names to try	Record type
Google Workspace	google (unless you chose another prefix)	TXT
Microsoft 365	selector1, selector2	CNAME
cPanel hosting mail	default	TXT
Fastmail	fm1, fm2, fm3	CNAME
Proton Mail	protonmail, protonmail2, protonmail3	CNAME
Newsletter and transactional services	Shown in that service’s domain settings	Usually CNAME

dig @OLD_NS google._domainkey.example.com TXT +short
dig @OLD_NS selector1._domainkey.example.com CNAME +short

A long "v=DKIM1; k=rsa; p=... string (TXT) or a target host name (CNAME) is a hit. To find the selector for certain, open a message you sent before the move, view its headers (Gmail: Show original; Outlook: View message details) and read the s= value in the DKIM-Signature line.

If the old zone is gone

Do not panic; every record can be rebuilt from its source.

• MX, SPF and autodiscover: your mail provider’s admin console lists the records it needs. Google Workspace and Microsoft 365 both show them, as covered in setting up Google Workspace email and setting up Microsoft 365 email.
• DKIM: Microsoft 365 shows the same two CNAME targets in the Defender portal. Google shows the existing key in Authenticate email, or you can generate a new one; publish it, then start authentication again.
• Old host mail: if your mail lived at the old web host, its control panel’s DNS or Email Deliverability page shows the records, and its support can send a zone export.
• Your own records: search your inbox for old DNS setup emails, a handover document, or the switching hosts checklist you filled in.

Step 3: Compare the old and new zones side by side

Before you edit anything, list every difference. This short loop asks both sets of nameservers the same questions and prints only what differs.

for name in example.com _dmarc.example.com autodiscover.example.com google._domainkey.example.com selector1._domainkey.example.com selector2._domainkey.example.com; do
  for type in MX TXT CNAME; do
    echo "== $name $type"
    diff <(dig @OLD_NS $name $type +short | sort) <(dig @NEW_NS $name $type +short | sort)
  done
done

Paste this into Terminal on macOS or Linux (it needs bash or zsh). Replace OLD_NS, NEW_NS and example.com first, and edit the list of names to include any selectors you found in Step 2. For each name and type it runs dig against both servers, sorts the answers so order does not matter, and diff shows lines starting with < (only in the old zone) or > (only in the new zone). A heading with nothing under it means both zones agree. Every < line under MX, TXT or a _domainkey name is a record you need to add to the new zone.

Two things to watch in the output:

• If the new zone has its own MX record as well as yours, delete the new host’s one. Senders use the lowest priority number first, and a leftover record can capture part of your mail.
• If both zones have an SPF record but with different content, do not add a second one. Merge them into one record, keeping your mail provider’s include and adding the new host only if the website sends mail directly. Two v=spf1 records make SPF fail for everything.

Step 4: Add the records at the new DNS provider

In the new provider’s DNS editor, add each missing record exactly as it was. Watch for these common mistakes:

• Doubled names. Many panels add your domain automatically. Entering _dmarc.example.com in the name field can create _dmarc.example.com.example.com. Enter just _dmarc, or @ for the root, unless the panel says otherwise.
• Long TXT values. DKIM keys are long. Paste the whole value; if the panel splits it into quoted chunks that is normal.
• Proxied records on Cloudflare. Mail-related CNAMEs such as DKIM and autodiscover must be “DNS only” (gray cloud). The guide to moving DNS to Cloudflare without breaking email covers the details.
• A low TTL. Set the TTL to 300 seconds (five minutes) for now so corrections spread quickly. Raise it again once everything has been stable for a few days.

Then check what the world sees, using the new nameserver and a public resolver:

dig @NEW_NS example.com MX +short
dig @1.1.1.1 example.com MX +short

The first confirms the new zone is right. The second asks Cloudflare’s public resolver, which may still show an older cached answer until its TTL expires. If the new nameserver is right and a resolver is not, wait; DNS changes not showing up explains caching and how long to expect.

Step 5: Fix autodiscover so Outlook and phones stop asking for passwords

Outlook and many phone mail apps look up autodiscover records to find your mail server. If the new zone sends them to the new web host, they connect to the wrong server, the password fails and the prompt repeats. Restore the provider’s record (for Microsoft 365, a CNAME from autodiscover to autodiscover.outlook.com), and remove any autodiscover A record or SRV record the new host created for its own mail service.

dig autodiscover.example.com +short
dig _autodiscover._tcp.example.com SRV +short

Good for Microsoft 365: the first returns autodiscover.outlook.com. followed by Microsoft addresses, and the second returns nothing or a Microsoft target. Bad: an IP address belonging to the new web host. Once fixed, devices may need to be restarted, or the account removed and re-added, to forget the wrong server. Mail apps that keep asking for a password covers the device side.

Step 6: Stop the new host keeping mail for itself

Many web hosts turn on a mail service for every domain they host. Even with the right public MX records, the web server may still believe it handles your mail. Then your WordPress contact form, which sends from the same server, delivers its messages into a local mailbox nobody reads, instead of out to Google or Microsoft.

• cPanel: Email, Email Routing, set to Remote Mail Exchanger.
• DirectAdmin: E-mail Manager, MX Records, uncheck “Use this server to handle my e-mails”.
• Plesk: turn off the mail service for the domain in Mail Settings, or ask the host.
• Enhance: the email settings for the website or domain; ask the host if the option is not visible to you.

Before you switch the mail service off, log in to the new host’s webmail or check its email accounts list. If mail was delivered there during the gap, move it out first: forward the important messages, or connect the mailbox to your mail app over IMAP and drag messages across. The hosting control panel cheat sheet shows where these settings live in each panel, and the full explanation is in website and email at different providers.

Step 7: Test that mail flows both ways

1. Inbound: from an outside account (a personal Gmail or Outlook.com address), send a message to two or three addresses on your domain, including any aliases or group addresses. Each should arrive within a few minutes.
2. Outbound: send from your business mailbox to that outside account. Open the message, view the original or headers, and check for spf=pass, dkim=pass with header.d=example.com, and dmarc=pass.
3. Website: submit your contact form and confirm the notification arrives in the real mailbox, not just “sent successfully”. WordPress not sending email helps if it does not.
4. Records: run your domain through the email diagnostic tool to see MX, SPF, DMARC and common DKIM selectors in one place, and the DNS lookup tool to check individual records from outside.

If outbound mail lands in spam for the first day or two after you restore SPF and DKIM, give it time and retest. Persistent spam placement is covered in emails going to spam after a DNS change.

Step 8: Deal with mail that bounced during the gap

• Ask staff to forward any bounce or “Undeliverable” message they received, and any client who says their mail bounced. The bounce text names the problem; email bounce codes explained decodes it.
• Tell key clients and suppliers that email was down between two stated times and ask them to resend anything important.
• Check your mail provider’s logs (Google Workspace email log search, Microsoft 365 message trace) for the period: they show which messages arrived and which did not.

If none of that worked

• The registrar shows the right nameservers but dig does not. Some registrars take time to publish changes to the top-level domain’s servers, and a mistake at the registrar (such as a typo in a nameserver name) breaks everything. Check with the domain lookup tool, which shows what the registry holds.
• DNSSEC was on at the old provider. If the registrar still holds DS records for the old provider’s keys, validating resolvers reject answers from the new nameservers and the whole domain fails for many people, website included. Remove the DS record at the registrar or set up DNSSEC at the new provider. DNS_PROBE_FINISHED_NXDOMAIN and “this site can’t be reached” covers the symptoms.
• You changed nameservers because the domain moved without your consent, or you do not recognize the new nameservers at all: treat it as a hijack and follow recovering a hijacked domain.

When you contact your new host or DNS provider, send: the domain, the old and new nameservers, the time of the change in UTC, the output of the comparison loop from Step 3, and a bounce message if you have one. Ask them specifically to confirm that the mail service for your domain is disabled on their server if your email is hosted elsewhere. Next time, the switching hosts checklist and moving WordPress by hand build the DNS check into the move itself.

See also

• Website and email at different providers
• Move DNS to Cloudflare without breaking email
• Transfer a domain without downtime
• Move email to a new provider without losing mail
• Emergency Room: email stopped working