Domain guide

DNS Migration Check Guide

DNS Migration Check asks two sets of nameservers the same questions and puts the answers next to each other. You give the domain, the nameservers it uses today and the ones you are about to delegate it to, and XGM queries both sets directly - the new ones are not delegated yet, which is the whole reason they have to be asked by name - for A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA. Each type gets a verdict: the same, different, missing on the new side, extra on the new side, or not answered. The comparison is by meaning rather than by text, so a different order is not a difference, MX is compared on priority and host, TXT on the joined strings, and a TTL change is reported apart from a content change, because moving hosts legitimately changes TTLs. A query that was refused or timed out is reported as not answered and never as missing - telling you a record is absent when the server simply did not reply is how a cutover loses mail. What comes out is a short list of what to fix before you switch, and a CSV of the whole comparison.

Open DNS Migration Check All guides

Beginner explanation

What this tool helps you understand

DNS Migration Check helps you check public domain signals behind the search intent "dns migration check".

Technical note

How to use the result safely

For production work, compare the XGM result with authoritative DNS, hosting, registrar or provider data before making critical changes.

Workflow

How to use DNS Migration Check

Follow this simple workflow before copying output or making production changes.

Enter the domain and the nameservers it uses today - the Domain Health or DNS Lookup tools will tell you if you are not sure.

Enter the nameservers you are about to move to, as your new provider gave them to you.

Run the check and read the fix list first: those are the records that would be missing or wrong the moment the delegation changes.

Correct the new zone at the new provider, run the check again, and switch only when the list is empty.

After the switch, lower the TTLs back and re-run Domain Health to confirm mail and TLS still resolve.

Use cases

When to use this guide

Check a public signal before or after a configuration change.
Troubleshoot what users, mail systems or browsers see from the outside.
Collect evidence before escalating to a provider, registrar or colleague.

Common mistakes

What to avoid

Forgetting DNS and routing data can be cached.
Assuming one clean result means the whole system is secure.
Changing production settings without rollback notes.

FAQ

DNS Migration Check FAQ

Quick answers for users arriving from search or comparing tools.

Why do I have to type the new nameservers myself?

Because they are not delegated yet. Until you change the nameservers at your registrar, the internet still sends every query for your domain to the old ones, so the only way to see what the new provider would answer is to ask it directly by name. That is also why this check is worth running: it is the only moment you can compare the two answers before the switch makes the new one the only one.

The new side shows nothing for a record type. Is it missing?

Only if the row says missing. A nameserver that refused the query or did not answer in time is reported as not answered, with the reason, and the summary says the comparison is incomplete - because a record reported as absent when the server merely failed to reply is exactly the mistake that loses mail after a cutover. Check that the nameserver name is right and that the zone has been created at the new provider before reading anything into an empty row.

Does a different TTL matter?

Not usually, and it is shown separately for that reason. A new provider has its own defaults and the records themselves are unchanged. TTLs do matter around the switch itself: lower them on the old side a day or two before you move, so a mistake propagates away in minutes rather than hours, and raise them again once the new zone has proved itself.

What about the SOA serial?

It gets its own finding when the new side is lower than the old one. Nothing breaks immediately, but a secondary that already holds the old zone will refuse to accept the new one as an update, and the mismatch surfaces later as two servers answering differently for the same name. Raise the serial on the new side above the old one before you switch.

Does this cover everything I need to move?

It covers the zone. It does not know about the things that live outside DNS: registrar transfer locks and auth codes, DNSSEC keys that have to be withdrawn before a move and re-added after, glue records for nameservers inside the domain itself, and any provider-side configuration such as mail routing or CDN certificates. The record comparison is the part that can be checked mechanically, and it is the part people usually get wrong.

Run the tool

Ready to check it?

Open the live XGM tool and use this guide while reviewing the result.

Open DNS Migration Check →

Related tools

Continue the dns migration check workflow

Open nearby XGM tools that help complete the same technical check.

DNS LookupLook up DNS records by type, including reverse (PTR) lookups for IP addresses.Domain HealthOne check for DNS, email authentication, TLS, security headers and redirects, with a grade per area and a full report.Email SecurityCheck SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI for a domain and get the records to fix them.MX & SMTPCheck a domain's mail servers and test SMTP connections, STARTTLS and open relay.

Related guides

More domain guides

Domain