Domain move broke website and email routing: DNS mismatch runbook

TL;DR — When a domain move breaks the website and email in different ways, the most common cause is that your DNS zone (the list of records for the domain) is split across old and new providers, or the website records were updated but the mail records were not. Start by checking which nameservers are active, then compare the live A/CNAME records for the website and the MX/TXT records for email in the active DNS provider. Reading time: ~6 min

The scenario

It is Tuesday afternoon, you have just pointed your domain at a new website host, and the homepage now loads from the new platform — at least on your laptop. Ten minutes later, your client says their email has stopped arriving, your contact form sends nowhere, and someone else still sees the old website. In your registrar (the company where the domain is registered), the domain looks "updated," but your email provider still says "DNS not found" and your web team swears they already changed the records. You now have one domain, two systems, and three different stories about where it lives.

Symptoms

• The website works for some people but not others.
• The website shows the old host, old content, or a parking page.
• The website returns errors like:
  • ERR_NAME_NOT_RESOLVED
  • DNS_PROBE_FINISHED_NXDOMAIN
  • 404 Not Found
  • 525 SSL handshake failed
  • Your connection is not private
• Email symptoms include:
  • New mail to you@yourdomain.com bounces with 550 5.1.1, 553, or No such user here
  • Sending from the domain fails SPF/DKIM/DMARC checks (email authentication records)
  • Your email provider dashboard says the domain is "unverified" or "MX records not found"
• DNS lookup tools show different answers depending on the record type:
  • A record points to the new web host IP
  • MX records still point to the old mail provider
  • TXT records for SPF/DKIM are missing or duplicated
• A DNS checker shows different nameservers than the ones you edited.

Likely causes

Step-by-step diagnosis

1. Check which nameservers are actually live for the domain.
   • Registrar dashboard path: your domain registrar → Domain settings → Nameservers.
   • Command:

dig NS yourdomain.com +short

• If the output shows nameservers from a different provider than the one you edited, this is your problem. Jump to Fixes → Wrong DNS provider / wrong active nameservers.

1. Check where the website currently resolves.
   • Command:

dig A yourdomain.com +short
dig CNAME www.yourdomain.com +short

• If yourdomain.com points to the new host but www.yourdomain.com points somewhere else, or one of them returns nothing, jump to Fixes → www and root domain point to different places.
• If both point where you expect, continue.

1. Check where email currently routes.
   • Command:

dig MX yourdomain.com +short
dig TXT yourdomain.com +short

• If MX records still point to the old provider, or the expected SPF record is missing, jump to Fixes → Website moved but mail DNS records did not.
• If there are two SPF records, that is also a problem; jump to the same fix section.

1. Confirm you are editing the live DNS zone, not a duplicate zone in another account.

   • Dashboard path: in your DNS provider's dashboard (for example, a DNS page often called DNS → Records), compare the records there with the nameservers from step 1.
   • What indicates the problem: you find a full zone in the old provider and another full zone in the new provider, but the registrar nameservers only point to one of them. Jump to Fixes → Old and new DNS zones both exist, but only one is live.

2. Rule out caching before changing more records.

   • Commands:

nslookup yourdomain.com 1.1.1.1
nslookup yourdomain.com 8.8.8.8
nslookup -type=mx yourdomain.com 1.1.1.1

• If public resolvers show the correct answers but your computer does not, this is likely cache/propagation. Jump to Fixes → DNS propagation or local cache.
• If public resolvers still show the wrong answers, continue fixing DNS rather than waiting.

1. Check whether the web server recognizes the new domain.
   • Command:

curl -I https://yourdomain.com

• If you see redirects to the old domain, a generic host page, or TLS (certificate encryption) errors, DNS may be correct but the web host is not configured for this domain. Jump to Fixes → Web server/app not configured for the new domain.

Fixes

Wrong DNS provider / wrong active nameservers

If you changed records in one provider but the registrar still delegates the domain to another provider, your changes are invisible on the internet.

1. In your registrar dashboard, open Domain settings → Nameservers.
2. Replace the old nameservers with the nameservers given by the DNS provider you actually want to use.
3. Save the change.
4. In the active DNS provider's dashboard, recreate or confirm these records at minimum:

@      A      203.0.113.10
www    CNAME  @
@      MX     10 mail.yourmailprovider.example.
@      TXT    "v=spf1 include:_spf.yourmailprovider.example ~all"
_dmarc TXT    "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
selector1._domainkey TXT "v=DKIM1; k=rsa; p=..."

Verify it worked:

dig NS yourdomain.com +short

You should now see the nameservers you intended to use.

Website moved but mail DNS records did not

This happens when someone updates A or CNAME for the website but forgets MX and TXT for email.

1. In the active DNS provider dashboard, open DNS → Records.
2. Add or correct the mail records from your email provider's setup guide. Typical records look like this:

@      MX     1 aspmx.l.examplemail.com.
@      MX     5 alt1.aspmx.l.examplemail.com.
@      MX     5 alt2.aspmx.l.examplemail.com.
@      TXT    "v=spf1 include:_spf.examplemail.com ~all"
selector1._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc TXT    "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

1. Remove old MX records that point to the previous mail provider.
2. If there are two SPF records, merge them into one. Example:

@ TXT "v=spf1 include:_spf.oldmail.example include:_spf.newmail.example ~all"

Do not keep two separate SPF TXT records starting with v=spf1.

Verify it worked:

dig MX yourdomain.com +short && dig TXT yourdomain.com +short

The output should show only the current mail provider and one SPF record.

Old and new DNS zones both exist, but only one is live

You may have a complete zone file in two places. Only the provider named in the live nameservers matters.

1. Identify the active provider from:

dig NS yourdomain.com +short

1. Log in to that provider and treat it as the source of truth.
2. Copy any missing records from the inactive provider into the active one. Focus on:
   • A / AAAA for website
   • CNAME for www
   • MX for mail
   • TXT for SPF, DKIM, DMARC
3. After you confirm the active zone is complete, delete or clearly label the inactive zone to avoid future edits in the wrong place.

Verify it worked:

dig A yourdomain.com +short && dig MX yourdomain.com +short

Both should match the records in the active provider.

DNS propagation or local cache

If public DNS is correct but your device still shows old answers, you may be seeing cached results.

1. Check public resolvers first:

nslookup yourdomain.com 1.1.1.1
nslookup -type=mx yourdomain.com 8.8.8.8

1. If those are correct, clear local browser and OS DNS cache.
   • Windows:

ipconfig /flushdns

• macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• Chrome/Edge browser cache page:

chrome://net-internals/#dns

Then click Clear host cache. 3. Retry from mobile data or another network to avoid office/router cache.

Verify it worked:

nslookup yourdomain.com

It should now match the public resolver answer.

www and root domain point to different places

A common partial migration: yourdomain.com works, but www.yourdomain.com still points to the old host.

1. In the active DNS provider dashboard, open DNS → Records.
2. Set the root domain and www consistently. Typical safe pattern:

@    A      203.0.113.10
www  CNAME  @

1. If your web host gave you a target hostname instead of an IP, use:

@    ALIAS   app.host.example
www  CNAME   app.host.example

Use ALIAS/ANAME only if your DNS provider supports it.

Verify it worked:

dig yourdomain.com +short && dig www.yourdomain.com +short

Both should resolve to the same destination.

Web server/app not configured for the new domain

DNS can be correct while the server still serves the old site or rejects the hostname.

⚠️ Changing web server virtual host settings or TLS certificates can cause downtime if done incorrectly. If your agency manages hosting, ask them to apply this during a low-traffic window.

For nginx (web server), confirm the server block includes the new domain:

server {
    listen 80;
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;
    root /var/www/site/public;
}

If the app has a site URL setting, update it in the app admin or environment config. Common examples:

APP_URL=https://yourdomain.com
SITE_URL=https://yourdomain.com

Then reload nginx:

sudo nginx -t && sudo systemctl reload nginx

If your host uses a control panel, the path is usually something like Sites → Domains → Add domain / Set primary domain.

Verify it worked:

curl -I https://yourdomain.com

You should get HTTP/2 200 or an expected redirect to the same domain, not the old one.

Prevention

• Lower DNS TTL (time to live, how long resolvers cache a record) 24 hours before a move so corrections spread faster. In your DNS dashboard, edit key records and set TTL to 300 seconds before migration.

@    A      203.0.113.10    TTL 300
www  CNAME  @               TTL 300

• Keep a pre-move record inventory in a text file or ticket. Export or copy all critical records before changing nameservers.

A/AAAA: root, www
MX: all priorities
TXT: SPF, DKIM selectors, DMARC, verification tokens
CNAME: www, autodiscover, mail aliases

• Add a post-change checklist to your deployment process that tests both web and mail.

dig NS yourdomain.com +short
dig A yourdomain.com +short
dig MX yourdomain.com +short
dig TXT yourdomain.com +short
curl -I https://yourdomain.com

• Put DNS under one clearly documented owner. In your password manager or runbook, store: registrar, active DNS provider, and email provider, with a note saying which one is authoritative.
• Add external monitoring for both website and mail DNS. Even a simple scheduled check from CI/CD can catch mismatches after a change.

test -n "$(dig +short yourdomain.com)" && test -n "$(dig +short MX yourdomain.com)"

• Avoid duplicate SPF records during provider transitions. Keep one SPF TXT record and merge includes while both systems are in use.

@ TXT "v=spf1 include:_spf.oldprovider.example include:_spf.newprovider.example ~all"

This article was written by an AI system and published pending human review. Verify anything you intend to act on.