How to Check Your DNS Records Before Changing Nameservers, So Nothing Breaks

Changing nameservers sounds like a small admin job. You paste in two new server names at your registrar and wait. The trouble is what that switch really does. It moves control of your whole DNS zone to a new provider, and the new provider usually starts with an empty zone. If a record is not recreated there first, it stops answering. Your homepage can keep working while your email quietly stops, a verification check fails, or a subdomain goes dark. The fix is simple: check the live records first, copy them exactly, and only then change the nameservers.

Start with the live answers, not a control panel

Do not trust the first DNS editor you find. An old hosting account can hold a set of records that is no longer in use, because the domain now points somewhere else. Find out which nameservers are actually authoritative for the domain right now, then check what those servers answer today.

Run the domain through our DNS Records Lookup and look at the A, AAAA, CNAME, MX, TXT and NS answers together. That is your starting inventory. Export the full zone from the current provider as well, so you have the exact values, priorities and TTLs to compare against. If the live answers and the panel disagree, believe the live answers and find out why before you move anything. Also note the TTL on each important record. TTL, or time to live, is how long resolvers may cache an answer before they ask again, and it decides how far ahead you must plan.

Check the website records, including the ones you forgot

Start with the bare domain and www. Check the A record for the bare domain and the AAAA record if the site uses IPv6, and check whether www is an A record, a CNAME alias, or something else. A missing www record is a classic own goal: the bare domain loads and www does not.

Then list every subdomain that does anything: shop, blog, app, api, login, help and booking. A subdomain that points to an outside service is easy to miss, yet it breaks just as completely if it is left behind. Check for a wildcard record too, since it answers for names with no record of their own. If your provider uses a special alias record for the bare domain, often called an apex alias, confirm the new provider has an equivalent before you switch.

Check the email records, because email breaks quietly

Email is what breaks first in most nameserver moves, and it breaks quietly. Mail simply stops arriving, or starts landing in spam, while the website looks fine.

Copy the MX records exactly, with their priorities. Lower priority numbers are tried first, so a swapped priority can send mail to the wrong server first. Then copy the TXT records that protect mail: the SPF record that lists which servers may send for your domain, the DKIM records under their selector names, and the DMARC record under its own _dmarc name. These strings are long and easy to truncate by hand, so copy them character for character and compare them after you recreate them. Check the mail setup with our MX Record Checker and our SPF, DKIM and DMARC Checker before the move, so you are not copying a broken setup to a new home. If someone else manages mail, get the exact values from them. Keep verification TXT records as well. Deleting one can break a check that took weeks to set up.

Check the quiet records: CAA, SRV and delegations

Some records cause no trouble on the day and real trouble later. A CAA record limits which certificate authorities may issue certificates for your domain. Drop it and everything keeps working until a certificate renewal weeks later fails. An SRV record points services such as chat or voice lookups at the right server and port. Check too for NS records that delegate a subdomain to different nameservers, and for DNSSEC. If DNSSEC is enabled, the registrar holds DS records that must be handled in the right order, or resolvers may treat the domain as broken. If the move already went wrong, our post on finding and fixing a broken DNS record works through the diagnosis in order. If you are unsure whether DNSSEC is on, check before you switch, not after.

Lower the TTL first, and wait for the old TTL to pass

Lowering the TTL saves the most pain, but only if you do it ahead of time. A day or two before the switch, lower the TTL on the records you will move to 300 seconds, which is five minutes. Then wait at least as long as the old TTL before you switch, so resolvers that cached the old long lived answer can expire it and pick up the short one. Lowering the TTL at the same moment as the switch does not help, because resolvers still hold the old answer for the old TTL period. A short TTL also does not promise that the nameserver change itself will finish in five minutes, because that delegation is cached at a higher level. Raise the TTL back to a normal value, often an hour, once everything is stable.

Recreate the zone before you switch, then verify

The order matters. First, recreate the full zone at the new provider and compare it line by line with the export you made. Second, if the new provider lets you query its nameservers directly, check the answers there before the switch, so a typo is caught while the old zone still serves the world. Third, change the nameservers at the registrar. Fourth, verify from the outside and watch propagation with our DNS Propagation Checker. If the new values are slow to appear everywhere, our guide to DNS propagation explains what is actually happening. A split result, with some locations on the new answers and some on the old, usually means caches are still expiring, not that the change failed.

Keep the old zone active for at least a few days after the switch. Do not delete it the moment the new one answers, because some resolvers will still ask the old nameservers during the changeover. Test the website on the bare domain and on www, send and receive a test email, and check any subdomain that matters. If something is wrong, the old export is your rollback plan: the exact values to restore, without guessing.

What to do first

Run the DNS Records Lookup on your domain today, before you touch any nameserver setting, and save the full result beside an export from the current provider. Copy every record, lower the TTL ahead of time, recreate the zone before you switch, and only then change the nameservers. Check, copy, then switch, in that order.