Changing nameservers moves responsibility for your domain's DNS from one provider to another. It is a single change made at your registrar, and it is the step that actually points a domain at new hosting, creating the account on the server does nothing until this happens.
It is also the change with the longest delay and the widest blast radius, because DNS controls the website and the email at the same time.
Before you change anything: write down the current DNS
This is the step people skip and regret, and it takes five minutes.
Changing nameservers hands the whole zone to the new provider, which starts from a default set of records. Anything custom in the old zone is not carried across. It is simply gone from the moment the change takes effect.
What gets lost, reliably:
- MX records if mail is handled by an external provider. Mail stops.
- TXT records: SPF, DKIM, DMARC, and any service verification.
- Subdomain records pointing at other platforms.
- CNAME records a service asked you to add.
Record every existing record before you touch anything:
dig ANY example.com dig MX example.com dig TXT example.com
Better, take them from the old provider's zone editor, which shows everything rather than only what a query returns.
Then recreate the ones you still need on the new provider before switching, so they are already in place when the change takes effect.
Making the change
Log in at your registrar, where the domain is registered, which is often not the same company as your hosting.
Find the nameserver settings. Registrars name it differently: Nameservers, DNS Settings, Manage DNS, Custom DNS.
Replace the existing entries with the two from your welcome email:
ns1.yourhost.com ns2.yourhost.com
Enter both. A single nameserver leaves you with no redundancy, and some registrars refuse to save it.
Save. The registrar submits the change to the registry, and it begins spreading.
How long it takes
Nameserver changes are slower than record changes, because they involve the registry rather than only your zone. Allow 24 to 48 hours, and tell clients up to 72, promising four hours and taking twelve generates a support conversation you did not need.
During the window, some visitors reach the old server and some the new one. That is expected and cannot be forced.
Lowering the TTL on your records a day before the change shortens the record-level part of this considerably. Understanding DNS propagation explains why it has to be done in advance.
Check it took
dig NS example.com
That should list the new nameservers. Until it does, nothing you configure on the new server is being consulted.
Compare two public resolvers to judge progress honestly:
dig @8.8.8.8 NS example.com dig @1.1.1.1 NS example.com
Do not judge from your browser. Layered caching means the person who made the change is usually the last to see it working.
Afterwards
Check mail first, not the website. The website failing is obvious; mail failing is silent, and it is the thing this change breaks most often. Send a message to an address on the domain from outside and confirm it arrives.
Reissue SSL. Certificates do not travel with a nameserver change. Once the domain resolves to the new server, run AutoSSL, and note it could not have succeeded before, because the authority could not reach the domain here.
Re-add the records you rebuilt. Confirm SPF, DKIM, DMARC and any verification records are actually present on the new provider, rather than assuming they were recreated correctly.
Keep the old hosting for a week. Mail delivered during propagation may have landed there. This is where mail genuinely gets lost.
Changing records instead
If you only need the website to move and mail to stay where it is, you may not need a nameserver change at all. Changing the A record at the current provider moves the site and leaves everything else untouched.
That is a smaller change with a shorter delay and far less to break. Use it when it applies. Understanding A records deals with editing one.
When it does not work
Registrar rejects the nameservers. A typo, or the hostnames genuinely do not resolve. Check them with dig ns1.yourhost.com.
48 hours later and dig NS still shows the old ones. The change was not saved, or it was made on a different domain. Check at the registrar.
Website works, mail stopped. The MX records were not recreated. This is the predictable one.
Some people see the old site. Normal during propagation. It resolves without intervention.
If you are moving DNS away from your host entirely, the order matters more. How to Move DNS to a Third-Party Provider goes into verifying before you switch.
When the change is part of moving to a new server, the sequence around it matters more than the change itself. How to Plan a DNS Cutover with No Downtime has the detail.
The records that do not travel with the nameservers
Changing nameservers moves the authority for the whole zone, and everything the old provider held is simply no longer consulted.
for t in A AAAA MX TXT CNAME NS SRV CAA; do echo "; $t"; dig "@$(dig example.com NS +short | head -1)" example.com "$t" +short done
Run that against the old provider before the change and keep the output. Mail records, domain verification strings, mail authentication records and any subdomain pointing at another service all live there and all stop working the moment the delegation moves.
Verification strings are the ones that cause a slow failure rather than an obvious one. A missing mail authentication record does not break delivery immediately; it degrades it over days, which is much harder to connect to a change made last week.
Check what the parent says, not only your provider
The registrar publishes the delegation and your provider answers for the zone. When those disagree, the world follows the registrar.
dig example.com NS +short dig example.com NS @a.gtld-servers.net +short dig +trace example.com | tail -12
The second command asks the level above your domain what it publishes. If it still lists the old nameservers, the change has not taken effect regardless of what the registrar's control panel shows.
The trace shows the whole path from the root and is the fastest way to see where the answer is coming from when the other two disagree.
Both sets of servers answer during the change
For a period, some visitors reach the new nameservers and some reach the old ones, and both answer confidently.
That means the old zone should be left in place and correct until the change has fully propagated, not deleted the moment the new one is live. Deleting it early is what turns a smooth change into an intermittent outage that is impossible to reproduce.
for ns in ns1.old.example ns1.new.example; do printf '%-22s %s\n' "$ns" "$(dig "@$ns" example.com A +short | tr '\n' ' ')" done
Both should return the same answer throughout. Once they do, the difference stops mattering and the old zone can be removed at leisure.