Setup

8 min read

Can an automatic DNS scan find everything on my domain?

A scan reads what your domain publishes. Several important things are not published, and knowing which is the difference between a clean move and a broken one.

Short answer

An automatic scan reads your domain's published DNS records — website, mail, authentication and ownership entries — quickly and accurately. It cannot see records on subdomains it was not told to check, it cannot know which records are still in use, it cannot see anything held in a private or internal DNS view, and it cannot tell you which of two similar records matters to you. Treat a scan as a very good first draft and review it against what you know.

Found reliably

Published, and therefore readable by anyone

Website records at the root and at www (advantage)
MX records and their priorities (advantage)
SPF, DKIM and DMARC entries (advantage)
Ownership proofs published as TXT (advantage)
Current nameservers (advantage)

Not found, or found without meaning

Where the review has to happen

Subdomains nobody thought to check — there is no list to enumerate (drawback)
Whether a record is still in use by anything (drawback)
Records in a private or split-horizon DNS view (drawback)
Which of two similar records is the load-bearing one (drawback)
Anything about to change — a service you are mid-migration on (drawback)

The left column is nearly always complete and correct. The right column is where migrations break, and no scan can close it for you.

How a scan actually works

A scan asks your domain's nameservers the same questions any mail server or browser would, and writes down the answers. It is fast, it is accurate about what it asks, and it changes nothing — it is exactly as intrusive as loading your website.

The limitation is structural rather than a quality problem, and it is worth stating plainly: DNS has no “list everything” operation. A scanner cannot ask “what records exist on this domain?” It can only ask “does this specific name exist?” — so it works from a list of names it already suspects.

A DNS scan cannot enumerate your domain. It can only check names it already guesses, which is why an unusual subdomain is invisible to it and obvious to you.

Good scanners guess well. They check the root and www, the mail records, the authentication records, and a list of common subdomains — mail, shop, blog, api, status, app. That covers the great majority of real domains. What it does not cover is the subdomain somebody created for a supplier's portal in 2021 and named after the supplier.

The four gaps, and how to close each one

1
Subdomains that were never guessed
Close it by looking, not by scanning: check your certificate provider for names you have issued certificates to, look through browser bookmarks for anything on your domain, and ask whoever set up suppliers whether any of them use a subdomain.
2
Records that exist but are no longer used
You cannot tell from DNS, and neither can a scanner. Do not try to work it out — carry everything across. An unused record costs nothing; a deleted record that turned out to matter can take days to trace.
3
Records in a private or internal view
Some organisations answer differently for internal networks. If your domain does this, the scan sees only the public half. Ask whoever manages internal DNS for their view before moving anything.
4
Which of two similar records is real
Scans find both and rank neither. Two TXT records that look like verification tokens are the classic case — one may belong to a service you left. Keep both unless someone can say which is dead.

The two answers a scan gives that are easy to misread

A scan can be entirely accurate and still leave you with the wrong impression, because two of its answers mean less than they appear to.

“No records found” is not the same as “nothing is there”

A scan run while a nameserver change is still settling can read the new, nearly-empty zone rather than the old, populated one — and report a domain with almost nothing on it. That is a true answer to the question it asked and a completely misleading picture of your domain. If a scan of an established domain comes back sparse, treat it as a reason to check what you are pointed at rather than as good news.

A record that resolves is not a record that works

A scan confirms an entry exists and has a plausible value. It does not confirm the service behind it is still paying its bills, that a DKIM key still matches the private half held by the sender, or that an SPF record's includes still resolve within the ten-lookup limit. Those are questions about behaviour, and only sending a real message answers them.

A scan proves

The records exist and read correctly

The entry is published and has the value you expect (advantage)
Syntax is plausible for its record type (advantage)
Nothing obvious is missing from the common set (advantage)

Only a real message proves

The records actually do their job

The DKIM key matches the private half the sender holds (advantage)
SPF still evaluates within the ten-lookup limit (advantage)
Mail is accepted rather than quietly filtered (advantage)
The service behind a record is still live (advantage)

The right column is the whole reason a migration is verified by sending mail rather than by comparing two record lists.

What a scan should show you before you accept it

The scan is not the risky part — accepting its output without reading it is. A tool that behaves well makes reading easy.

Every record it found, in full. Not a summary and not a count. If you cannot see the values, you cannot compare them to what you know.
A clear statement of what it will do to each one. Carried across unchanged, replaced, or added. A record whose fate is unstated is a record you should ask about.
A separate confirmation step. Reading a domain and rewriting it are different actions and should be different clicks.
A way to add records by hand. Because the gaps above are real, and the person who knows about them is you.

Checking afterwards, which matters more than checking before

The most reliable verification is not a comparison of two lists. It is loading the things your domain actually does.

First 15 min
Load the website and the www version
Both, separately. They are different records and one can be missed without the other.
First 30 min
Open every subdomain you know about
The shop, the booking page, the status page, the supplier portal. This is where scans miss things.
First hour
Complete a real transaction
A test order, a booking, a form submission. Payment processors verify domains, and that verification is a record.
First day
Send and receive a real message
In both directions, to and from an outside provider — not to yourself.
First week
Ask whether anything looks different
Colleagues notice broken things you do not use. This is the check that finds the subdomain nobody remembered.

Checking early catches the records that were missed while the old ones are still recoverable. Checking only after everything settles is how a missing subdomain becomes a week of confusion.

What to remember

DNS has no “list everything” operation. A scan checks names it guesses, so an unusual subdomain is invisible to it.
A scan cannot tell whether a record is still in use. Carry everything across; unused records cost nothing.
Certificate transparency logs are the best way to find subdomains you have forgotten.
Insist on seeing every record found, in full, with a statement of what happens to each — and a separate confirmation step.
Verify by loading the things your domain does, not by comparing two lists. Check subdomains and a real transaction within the first hour.

Questions people ask next

Why can't a DNS scan just list every record on my domain?

Because the protocol has no operation for it. A resolver can ask whether a specific name exists but cannot ask a nameserver to enumerate everything it holds — a deliberate design choice, since enumeration would be a gift to anyone mapping a target. Scanners therefore work from a list of likely names.

How do I find subdomains I have forgotten about?

Search public certificate transparency logs for your domain: every certificate ever issued is recorded there, including for subdomains, and certificates are usually issued for names genuinely in use. Then check your bookmarks and ask whoever set up supplier integrations.

Should I delete records the scan found that I do not recognise?

No. An unrecognised record is far more likely to be something you have forgotten than something harmful, and an unused DNS record costs nothing. Carry it across and revisit in a few months, once you have seen what nobody missed.

Is running a scan on my domain safe?

Yes. It reads public data using the same queries any mail server makes when delivering to you, and writes nothing. The step that changes your domain is separate and requires your confirmation.

What if my organisation runs internal DNS as well?

The scan sees only the public view, which for a split-horizon setup is half the picture. Ask whoever manages the internal view for their records before moving anything, because internal names are exactly the ones nobody outside the network can discover.

How accurate are scans for the records they do find?

Very. For anything published — website, mail, authentication and ownership records — a scan reads the same authoritative answers everyone else gets. The uncertainty is never about accuracy; it is about completeness.

My scan came back almost empty on an established domain. What does that mean?

Usually that it read the wrong zone — most often a new one that is still being populated during a nameserver change, rather than the old one still serving the internet. A sparse result on a domain you know is busy is a reason to check which nameservers you are pointed at, not a reason to relax.

If every record checks out, is the migration definitely fine?

No. A scan confirms records exist and read correctly; it cannot confirm that a DKIM key still matches the private half the sender holds, that SPF still evaluates within its lookup limit, or that the service behind a record is still live. Those only show up when a real message is sent and delivery is observed.

Trusted references

Last reviewed 2026-08-16 · Brand My Inbox current