Changing nameservers is the single riskiest routine operation in DNS. Not because it is difficult — it is two minutes of clicking at your registrar — but because it replaces your entire DNS configuration in one step, and the internet takes up to two days to agree on the result.
Done in the wrong order, it takes the site down for a day and quietly stops your email. Done in the right order, nobody notices.
What actually changes
Your registrar holds a delegation: a short list of nameservers, published in the parent zone, that tells the world which servers are authoritative for your domain. For a .com, that list lives at Verisign.
When you change nameservers, you are not moving your DNS records. You are pointing the internet at a different set of servers and hoping the records are already there. The old provider's records do not travel with you. If the new nameservers have no records for your domain, the domain stops resolving entirely the moment resolvers pick up the change.
That is the whole risk, and it explains why the order of operations matters so much.
Two other properties make this different from an ordinary record change:
You do not control the TTL. Delegation records in the parent zone carry a TTL set by the registry — 48 hours for .com. You cannot lower it. This is the one DNS change where the traditional "up to 48 hours" advice is roughly accurate.
Both sets of nameservers will be live at once. During the transition, some resolvers ask the old servers and some ask the new ones. There is no moment where traffic cleanly switches. Both configurations must be able to serve your site correctly, simultaneously, for as long as the transition lasts.
The sequence
1. Record what you have
Before touching anything, export the complete record set from the current provider. Most offer a zone file export; if yours does not, copy every record by hand — type, name, value, TTL and priority.
Run your domain through the DNS Checker as well and save the output. It gives you an independent record of what the world could actually see, which is the thing you will be comparing against afterwards. Do not rely solely on the old provider's control panel: you are about to stop paying attention to it, and in some migrations you lose access to it entirely.
Pay particular attention to records you did not create and might not think about:
- MX records and any mail-related TXT records. Email is what people forget, and email failures are silent — senders get a bounce, you get nothing.
- SPF, DKIM and DMARC TXT records. Losing these does not stop mail; it sends it to spam, which is worse because it looks like it is working. See SPF, DKIM and DMARC explained.
- Domain verification TXT records for Google Workspace, Microsoft 365, Facebook and similar. Losing one can un-verify a service days later.
- Subdomains pointing at services you do not think about — status pages, mail subdomains, staging environments, CDN endpoints.
2. Build the zone at the new provider first
Recreate every record at the new provider before changing the delegation. All of it, exactly as it was.
This is the step that makes the migration safe. When the delegation eventually changes, the new servers already answer correctly, so a resolver switching over sees no difference at all.
Set TTLs low — 300 seconds — on the records themselves while you do this. It will not speed up the delegation change, but it means that if you find a mistake afterwards, fixing it takes five minutes rather than a day.
3. Verify the new servers before anyone is using them
You can query the new nameservers directly, by name, before the delegation points at them. This is the most under-used step in the whole process, and it is the one that catches typos while they are still harmless:
dig @ns1.newprovider.com example.com A
dig @ns1.newprovider.com example.com MX
Ask every new nameserver, not just the first. A zone that has only partially loaded across a provider's fleet is a real failure mode, and it produces an intermittent outage that is miserable to diagnose after the fact.
4. Lower the SOA minimum if you can
Some providers let you set the negative-caching TTL, published in the zone's SOA record. It controls how long resolvers cache the absence of a record. If a resolver asks for something during the window when your zone is incomplete, it will cache that "does not exist" answer for this long. Setting it low limits the damage from a mistake.
5. Change the delegation
Now update the nameservers at the registrar. Change all of them in one edit rather than one at a time — a mixed delegation, with some old and some new servers, means resolvers get answers from either set at random.
6. Leave the old provider running
Do not cancel the old DNS service, and do not delete the zone. For at least a week, ideally two.
Resolvers will keep asking the old servers until the parent zone's 48-hour TTL expires everywhere, and some ISP resolvers hold delegations longer than they should. As long as the old zone still answers correctly, those stragglers get the right answer and nobody notices. Delete the zone and they get nothing.
This is free, it costs you only the delay before cancelling, and it is the difference between a partial outage and none.
Verifying the change
Check with the DNS Checker rather than by loading the site in your browser. Your browser tells you what your machine currently thinks, which is one data point and probably a cached one.
Watch the NS row first. It shows what each resolver currently believes the delegation to be, and the transition will be visible: some resolvers on the old servers, some on the new, each with a TTL counting down. That is expected and not a fault.
Then compare the A, MX and TXT rows across resolvers. This is the check that matters. If some resolvers are on the old nameservers and some on the new, but every resolver returns identical records, your migration is correct — the two configurations agree, so it does not matter which one a visitor reaches. That is exactly what step 2 was for.
If the answers differ depending on which nameservers a resolver is using, you have a mismatch between old and new zones. Fix the new zone now, while the old one is still covering for you.
What to do when it goes wrong
The site is down for some visitors. Compare the two zones record by record. Almost always something is missing at the new provider. Add it — the fix reaches resolvers within the record TTL, which is minutes if you set them low.
Email stopped. Check MX records at the new provider first, then the SPF and DKIM TXT records. Mail servers cache MX lookups too, so allow for the TTL before assuming a fix has not worked.
The registrar shows the new nameservers but the DNS Checker shows the old ones. This is normal for up to 48 hours. The registry has your change; resolvers are still holding the old delegation. Nothing is broken and nothing can speed it up.
Everything is stale far beyond 48 hours. Check that the nameservers you entered are spelled correctly and actually exist. A delegation pointing at a nonexistent hostname is a lame delegation: some resolvers fall back to the old cached answer and appear to work, which makes the problem look intermittent rather than total.
The short version
Copy the zone. Rebuild it completely at the new provider. Query the new servers directly to confirm they answer correctly. Only then change the delegation — and leave the old provider running for two weeks afterwards. The 48-hour wait is unavoidable, but if both configurations answer identically, the wait costs you nothing.