Changing your nameservers is one of the most powerful things you can do to a domain, and one of the easiest to get wrong. You do it when you move your DNS to a new host or DNS provider: a new web host, Cloudflare, or a dedicated DNS service. The switch itself takes two minutes at your registrar. The danger is that flipping nameservers hands your entire domain to a new set of servers, and if those servers do not already have your records, your website and email go dark the moment the change takes hold. This walks through how to change nameservers safely, the one step almost everyone skips, and how to confirm it worked.
What nameservers actually do
Your nameservers are the servers that hold the authoritative answers for your domain: your A records, MX records, TXT records, everything. When someone looks up your domain, the lookup is ultimately directed to your nameservers to get the real answer. Your registrar (where you bought the domain) stores which nameservers are in charge, and your DNS provider (which may or may not be the same company) is where the actual records live. Changing nameservers means telling your registrar to point at a different provider's servers. That is why it is all-or-nothing: you are not moving one record, you are moving who answers for the whole domain. For the full picture of how this delegation works, see how DNS delegation works.
Before you change anything: copy your records
This is the step people skip, and it is the one that causes the outage. When you switch nameservers, the new provider answers for your domain, but only with the records you have set up there. If you moved your nameservers before recreating your records, the new provider has nothing to serve, and your site and email vanish until you fix it.
So before you touch the nameservers, log in to your current DNS and write down every record: your A and AAAA records, any CNAMEs, your MX records, and all your TXT records, including SPF, DKIM, and DMARC. Then recreate all of them at the new provider first. Our DNS migration checklist covers this record-by-record. Only when the new provider has a complete copy of your zone should you move the nameservers. Done in this order, the switch is seamless, because both old and new providers can answer correctly during the transition.
How to change the nameservers, step by step
- Get the new nameservers. Your new host or DNS provider gives you two or more nameserver names, usually something like ns1.provider.com and ns2.provider.com.
- Log in to your registrar. This is where you bought the domain, which is not always where your website is hosted.
- Find the nameserver setting. It is often under the domain's management page, labeled Nameservers, DNS, or similar. It usually shows your current nameservers.
- Replace them with the new ones. Remove the old entries, enter the new ones exactly as provided, and save.
That is the whole change at the registrar. Nothing appears to happen immediately, which is normal.
What happens next: propagation
Nameserver changes are not instant. Resolvers around the world need time to notice the new nameservers, and the delay depends on caching at the top-level-domain level and elsewhere. It usually settles within a few hours and can take up to a couple of days in the slowest cases. During this window, some visitors reach the domain through the old nameservers and some through the new ones, which is exactly why you recreated your records first: both sets answer correctly, so no one sees an outage. To understand the timing, see DNS propagation and TTL.
Do not delete the old zone yet
Leave your old DNS records and hosting in place until the change has fully propagated and you have confirmed everything works on the new provider. Tearing down the old setup the same day is a common way to cause an outage for the visitors still being routed to the old nameservers. Give it at least a couple of days, verify, and only then decommission the old zone.
Verify the change worked
Once you have given it time, confirm the switch. You can query your domain's NS records with dig to see which nameservers are being reported, and check that your site loads and your email flows. The fastest way to confirm the whole domain is healthy on its new home is to run it through the Domain Health Report, which checks delegation, your records, and mail in one pass, so you can see at a glance that nothing got left behind in the move.
Nameservers versus individual records: know which you are changing
A lot of confusion comes from mixing up two different changes. Editing an individual record, like updating your A record to point at a new web server, is a small, surgical change: everything else about your domain stays exactly where it is. Changing your nameservers is the big one: it moves the entire zone to a new provider, so every record has to already exist there. If your goal is just to move your website to a new host but keep your DNS and email where they are, you often do not need to change nameservers at all. You only update the A record. Reach for a nameserver change when you actually want a new company managing all of your DNS, not when you want to move a single service. Getting this distinction right saves a lot of unnecessary risk, because the smaller change cannot take your email down the way a botched nameserver switch can.
Common problems
- Site or email down right after the switch. Almost always means the records were not recreated at the new provider first. Add the missing records there.
- Vanity or custom nameservers. If you use nameservers on your own domain, you may also need glue records at the registrar so they can be found. See how DNS delegation works.
- It looks unchanged after an hour. That is usually just propagation. Confirm the new nameservers are set correctly at the registrar, then wait it out rather than changing things again, which only resets the clock.
Changed in the right order, a nameserver move is quiet and safe: copy your records, switch, wait, verify, then retire the old setup.