A DNS quick scan can miss unusual hostnames and custom DKIM records. Compare the source inventory, service requirements, and target zone before a nameserver move.
A DNS scan has finished. The new dashboard shows a website address, a www record, and mail records. Is the domain ready for a nameserver move? Not on that evidence alone. A completed discovery step does not prove that every record your services need is present in the target zone. Cloudflare makes this limitation explicit in its DNS records quick scan documentation .
Its scan uses recurring combinations of record type and name. Unusual hostnames and custom DKIM names can be missed. This is documented behavior for Cloudflare's quick scan, not a claim that every DNS tool uses the same method.
For a buyer preparing to use an acquired domain, or an operator moving DNS for an existing business, the useful question is: which required records have we verified, and which remain unknown? Why common records can appear while an important one is missing Cloudflare explains that many zones share familiar type-and-name pairs, such as an A record at the domain apex, a www record, or mail-related records.
Its discovery process looks for recurring patterns rather than starting with a complete inventory tailored to your domain. The guide gives specific examples of gaps: an unusual hostname such as my-store1900.example.com , or a custom DKIM name such as this._domainkey rather than default._domainkey . Finding familiar records does not establish that those less predictable names were found too.
Cloudflare's full-setup guide therefore calls for a record review before changing nameservers, with attention to the apex, subdomains, and email records. Do not use a successful homepage check as a substitute for that review. Compare three sources before approving the target zone Use a small reconciliation worksheet.
This is an editorial checklist for the authorized DNS owner, not an instruction to change records or switch nameservers now. The current DNS inventory: obtain a dated record list or supported export from the DNS service you are authorized to manage. Record which zone and provider it covers. Public lookups and a quick scan are useful evidence, but neither should be treated as your complete source inventory.
The services you intend to keep: ask the website, email, application, and other service owners to confirm their required hostnames, record types, and current provider-supplied values. Mark old or unrecognized dependencies for review rather than assuming they must be copied. The proposed target zone: compare each required entry with what the new provider actually holds.
Review the full name, type, value, and applicable fields such as priority or TTL. Record unresolved differences and who must resolve them. A source export is a better starting artifact than memory, but it is not automatic proof that every application dependency or provider setting has been captured. Cloudflare documents zone import and export separately, including provider-specific record attributes.