Changing nameservers without website or email downtime

Switching nameservers is one of those jobs that feels like a two-minute form. You paste four hostnames at the registrar, click save, and the whole internet begins asking a different company for every answer about your domain. If that company's zone is missing even one row, the corresponding service goes dark. This guide sets out a careful method for changing nameservers so that visitors and, more importantly, email never notice the switch.

The method matters most when mail lives somewhere other than the website, which is true for nearly every business using Google Workspace, Microsoft 365 or Zoho.

Be clear about why you are moving

Before starting, confirm the move is necessary. If you only want the website on a new server, editing the A record in your existing zone is a smaller and safer change. A nameserver move is justified when you are adopting a CDN, consolidating providers, leaving an agency's account, or your current DNS provider is unreliable.

Write down the destination and the reason. If neither is clear, do not proceed.

Step one: capture the complete current zone

This is the step that decides whether the migration succeeds. Open the panel that is currently authoritative and record every single row: name, type, value, priority and TTL.

• Use the panel's export function if it has one, and save the file outside the website.
• Screenshot the full list as a second copy, scrolling so nothing is cut off.
• Pay attention to rows you do not recognise, especially TXT records used for service verification, since removing one can log you out of a marketing or analytics tool weeks later.
• Note records for subdomains: staging, help centres, tracking hostnames, VPN endpoints.
• Ask your mail provider for their current recommended MX, SPF and DKIM values so you can compare against what you captured.

Count the rows. You will check that number again after rebuilding.

Step two: build the zone at the new provider before switching

Create the domain at the new DNS host and enter every record you captured, while the old nameservers are still live. Nothing you do here has any effect until the registrar points at them, which makes this stage completely safe.

1. Enter web records first: A, AAAA and any CNAMEs including www.
2. Enter MX records with the same priorities.
3. Enter TXT records exactly, watching for line breaks introduced by copy and paste in long DKIM keys.
4. Enter any SRV, CAA or subdomain delegation records.
5. Delete the new provider's default placeholder records, which often point at their own parking page or mail service and will silently override yours.
6. Set TTLs on the records you expect to verify to 300 seconds for the migration window.
7. Compare the row count and read the list once more against your export.

If the new provider offers a scan-and-import feature, use it as a starting point, not as the finished job. Such scans routinely miss records that are not published in obvious places.

Step three: prepare the timing

Nameserver delegation is cached with its own long lifetime, so old resolvers may keep using the previous nameservers for many hours after the registrar update. Plan for both zones to be in use simultaneously.

The practical consequence is simple: leave the old zone untouched and the old servers running throughout. If both zones hold identical records, it does not matter which one a visitor's resolver uses, and the transition becomes invisible.

Choose a low-traffic window, ideally early morning midweek, and avoid the days around a sale, a product launch or a public holiday when support staff are unavailable. Tell colleagues the date so nobody reports normal caching behaviour as an outage.

Step four: make the switch and watch

At the registrar, replace the nameserver list with the new one, entering all of the hostnames the new provider supplies. Save, and note the exact time.

Then verify in this order:

• Query the NS records from a public lookup tool to see the new values appearing.
• Load the website over both www and the bare domain, on office broadband and mobile data.
• Check that the certificate is still valid, particularly if the new provider proxies traffic.
• Send a test email from an outside account to a company mailbox, and reply from it.
• Check a second mailbox on the same domain, since aliases sometimes route differently.
• Confirm that transactional mail from the website still arrives, such as an order confirmation or a contact form notification.
• Look for anything that logs in with the domain, such as marketing tools relying on a TXT record.

Repeat the email checks a few hours later and again the next morning, because mail is the service that fails quietly and the failure may only show on some sending networks.

Keep a rollback ready

Rollback for this change is straightforward, provided you did not dismantle anything. If something is badly wrong, set the nameservers back to the original values at the registrar. Because the old zone is untouched and the old servers still run, service returns as resolvers pick up the change.

Two conditions make that possible, so protect them: do not delete the old zone, and do not cancel the old hosting account for at least a week or two after the move. Many people cancel the day they switch, which turns a reversible change into a rebuild.

Also keep the registrar login separate and accessible. If the registrar account itself is part of the migration, complete and verify the nameserver change first, then deal with the transfer later.

Finish the job a week later

Once everything has been stable for several days, raise the short TTLs back to an hour or more, update your written domain map with the new DNS host, and only then close the old account. Note the date of the change in your site changelog so a future problem can be matched against it. If you would rather have the whole sequence planned and verified for you, our team does these migrations regularly as part of managed support.

Frequently asked questions

Will my website go down when I change nameservers?

Not if the new zone contains the same records and the old servers stay online during the overlap. Downtime happens when a record is missing or the old host is switched off too early.

How long should I keep the old DNS zone?

At least a week after the change, and longer if you can. It costs nothing to leave in place and is your fastest route back if a problem appears.

Can I change nameservers without affecting email?

Yes, as long as the MX records and the mail-related TXT records are recreated exactly at the new provider before the switch. Test with real messages in both directions afterwards.

What if I do not know all my current DNS records?

Ask the current DNS provider for a zone export, and list every service that uses your domain, such as mail, analytics, chat and payment tools, so you can request the correct values from each before moving.