DNS Migration Check
Compare what your current and your new nameservers answer, record by record, before you switch the delegation.
Related tools
- 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.
About this tool
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.
Moving a domain to new DNS hosting is a delegation change: the moment the registrar's NS records point at the new set, every answer comes from the new zone. Anything the old zone answered and the new one does not simply stops existing, and the records that go missing most often are the ones nobody set up in the panel - a TXT verification, a subdomain CNAME, a CAA record, an SRV entry for a phone system.
This queries both sets directly, so it works before the switch and does not depend on what is delegated today. A query that fails is reported as a failure, never as an empty side. To check the zone you are moving to on its own, use DNS Lookup; for the mail records specifically, Email Security.
How to use it
- 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.
FAQ
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.