How to Change Your Domain's Nameservers Safely

Moving your DNS to a new provider, such as a CDN, a new host or a dedicated DNS service, means you have to change nameservers at your domain registrar. It is a two-minute task in the registrar's control panel, but done carelessly it is also one of the easiest ways to take a website and its email offline at the same time. The secret is that almost all the work happens before you click save.

What nameservers do

Your domain's nameservers (also written "name servers") are the servers that hold the authoritative copy of its DNS records: the A records for your website, MX records for email, TXT records for SPF and verification, and so on. The registry for your domain's extension, such as .com or .in, keeps a pointer called a delegation that says "for example.com, ask these nameservers". You set that pointer through your registrar.

When you change nameservers, you are not moving records. You are telling the world to stop asking the old servers and start asking the new ones. Whatever the new servers contain, or fail to contain, becomes your live DNS.

Why it goes wrong

The classic failure looks like this: a business signs up with a new host, the host says "change your nameservers to ns1.newhost.com and ns2.newhost.com", the owner does so, and the website works. A day later someone notices no email has arrived. The new zone only contained the website records; the MX, SPF and DKIM records were never copied across. Everything in this guide is designed to avoid that.

Step 1: Record what you have now

Before changing anything, take a complete inventory of the current zone. Do not rely on memory or on what you think is there.

Export the zone file from your current DNS provider if it offers an export (many do, in standard BIND format).
If not, screenshot or copy every record from the control panel, including TTLs.
Cross-check with a public lookup. Our DNS lookup tool shows what is actually being served, which sometimes differs from what you expect.

Pay special attention to records that are easy to miss: TXT records at subdomains (_dmarc, selector._domainkey), CNAMEs used for email tracking or SaaS tools, SRV records for phone systems or Microsoft 365, and CAA records.

Step 2: Build the zone at the new provider

Add the domain at the new DNS provider and recreate every record. Some providers scan your existing DNS and import records automatically; treat that as a starting point and compare it line by line against your inventory, because automated scans can only find names they guess.

Watch for provider differences:

Some panels want the full name (mail.example.com), others only the label (mail). Entering the full name in a label field can create mail.example.com.example.com.
Long TXT records such as DKIM keys may need to be pasted without the surrounding quotes or line breaks.
Root-level "CNAME" features (ALIAS, flattening) may not exist at the new provider.

Step 3: Test the new nameservers before switching

You can query the new servers directly even though the world is not using them yet. That lets you prove the zone is correct before a single visitor depends on it:

dig @ns1.newprovider.net example.com A +short
dig @ns1.newprovider.net example.com MX +short
dig @ns1.newprovider.net example.com TXT +short
dig @ns1.newprovider.net _dmarc.example.com TXT +short

On Windows, use nslookup -type=MX example.com ns1.newprovider.net. Compare every answer with the same query against the old nameservers. They should match exactly.

Step 4: Check DNSSEC

If DNSSEC is enabled on the domain, a careless nameserver change can make your domain fail to resolve for every validating resolver. The registry still holds a DS record that matches the old provider's signing key, and the new provider's answers will not match it. The safe approach for most small businesses is to remove the DS record at the registrar, wait for its TTL to expire (often a day or two), change nameservers, then enable DNSSEC at the new provider and add its new DS record. Larger operations can do a key rollover between providers, but that requires both sides to cooperate.

Step 5: Change the nameservers at the registrar

Log in to your registrar (the company you pay for the domain, which may not be your host). Find the nameserver or DNS settings, choose custom nameservers, and enter the new ones exactly as given. Usually there are two to four. Remove all the old ones; mixing old and new nameservers means some resolvers get one zone and some get the other.

If you are unsure who your registrar is, a WHOIS lookup on your domain will show the registrar's name and the current nameservers.

Step 6: Keep the old zone alive and verify

The delegation records at the registry carry their own TTL, commonly up to two days, and you cannot lower it. During that window some resolvers will still ask the old nameservers. So:

Do not delete the zone at the old provider for at least a few days. Ideally do not edit it either, or keep any edits in sync on both sides.
Watch the switch spread with the DNS propagation checker, querying the NS record type.
Send test emails to and from the domain, load the website over HTTPS, and check any subdomains used by staff or customers.

A short pre-flight checklist

Full export of the current zone saved.
All records recreated at the new provider, including email and subdomain TXT records.
New nameservers queried directly and answers match the old ones.
DNSSEC handled (DS removed, or a coordinated key rollover planned).
Change scheduled for a quiet period, not late on a Friday.
Old provider left in place until propagation is complete.

Key takeaways

Changing nameservers swaps your entire DNS in one go, so the new zone must be complete before you switch.
Email records are the ones most often forgotten; check MX, SPF, DKIM and DMARC explicitly.
Query the new nameservers directly to test before switching, and leave the old zone running afterwards.
Deal with DNSSEC first, or the domain may stop resolving entirely.

DNS & Domains articles