
Changing nameservers is the riskiest DNS operation most website owners perform. Done incorrectly, it results in your domain going dark — website down, email bouncing, subdomains unreachable — for hours or days until DNS propagates everywhere.
Done correctly, the transition is seamless. Here's the exact sequence.
The danger is the gap between when you change your nameservers at the registrar and when the rest of the internet stops asking your old nameserver. During that gap, some resolvers are getting answers from your old nameserver and some from the new one.
If your new nameserver doesn't have all the same DNS records as the old one, queries that hit the new nameserver return NXDOMAIN (domain not found) or wrong results — even though your old records are still working fine for everyone else.
The root cause of most nameserver migration downtime: records missing at the new nameserver.
# Export your current DNS zone — do this BEFORE making changes
dig yourdomain.com ANY +short
dig yourdomain.com A +short
dig yourdomain.com MX +short
dig yourdomain.com TXT +short
dig yourdomain.com CNAME +short
dig www.yourdomain.com CNAME +short
dig mail.yourdomain.com A +short
# More thorough — query against your current authoritative NS
CURRENT_NS=$(dig yourdomain.com NS +short | head -1)
dig yourdomain.com ANY @$CURRENT_NS
List every record. Include subdomains you use for email (mail., smtp.), services (app., api., status.), third-party verification TXT records (Google Search Console, domain ownership verifications), and SPF/DKIM/DMARC records.
Email-related records are the most commonly missed. A site going down for a few hours is bad; email bouncing for 48 hours is a serious business problem.
Log into your new DNS provider and create every record from your audit. Verify each one:
# Verify records exist at the new nameserver BEFORE switching
NEW_NS="ns1.yournewdnsprovider.com"
dig yourdomain.com A @$NEW_NS +short
dig yourdomain.com MX @$NEW_NS +short
dig yourdomain.com TXT @$NEW_NS +short
dig www.yourdomain.com CNAME @$NEW_NS +short
Every record should return the same result as your current nameserver. Don't proceed until they do.
Before switching, reduce the TTL on all records at your current nameserver to 300 seconds (5 minutes):
# Verify current TTL
dig yourdomain.com A +ttl
# The number after the name in the answer section is the TTL
Wait for the current TTL to expire. If your TTL was 86400 (24 hours), you need to wait 24 hours after lowering it before the new low TTL is seen everywhere.
This step shortens the propagation window. After the nameserver switch, changes will spread within 5 minutes rather than 24+ hours.
Log into your domain registrar and update the nameserver settings to point to your new DNS provider. The change takes effect immediately at the registrar; propagation to the rest of the internet follows.
# Check what different resolvers are seeing
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
echo -n "$ns: "
dig yourdomain.com NS @$ns +short
done
You're looking for all resolvers to return your new nameservers. During propagation, you'll see a mix of old and new — this is normal. See DNS propagation taking too long? What to check first if things haven't updated after the TTL has expired.
Once propagation is complete and you've confirmed everything is working correctly, raise TTLs back to a sensible value (3600–86400 seconds depending on how frequently records change).
yourdomain.com → IP)v=spf1 ...)mail._domainkey.yourdomain.com)_dmarc.yourdomain.com)api., app., status., mail.)If you've changed nameservers and something is broken, the fastest fix is usually to go back to the old nameserver while you sort out what's missing:
Domain Monitor monitors your DNS records continuously. After a nameserver migration, DNS record monitoring confirms that all records are propagating correctly and alerts you immediately if any record unexpectedly reverts or changes. Create a free account.
Wildcard, SAN (multi-domain), and single-domain SSL certificates cover different use cases. Here's a clear comparison to help you pick the right type — and avoid paying for coverage you don't need.
Read moreDNS resolves correctly from your office but fails for users in other countries or on different ISPs. Here's why geographic DNS inconsistency happens and how to diagnose which layer is causing it.
Read moreRegistrar lock and transfer lock are often confused — and disabling the wrong one leaves your domain vulnerable. Here's a clear breakdown of what each does and when to use them.
Read moreLooking to monitor your website and domains? Join our platform and start today.