Treat the discovered host list as an inventory of your public surface that you then reconcile against your own DNS and hosting records. It will show you things you forgot. It will also miss things, and it is worth knowing which.
Why dead names keep appearing
Discovery draws on public certificate records, and those are permanent. A name whose service was retired in 2023 still shows up, usually with a DNS failure, a private address, or a connection timeout beside it.
That is a feature. A retired name that still resolves is worth a look. A retired name that does not resolve is a row you can cross off your DNS zone.
What it is not is proof that a forgotten server is still running. The name existing and the service existing are different claims.
A certificate can also carry names belonging to a shared host or another organization entirely. Adjacent domains covers those relationships without pretending they imply ownership.
Why a live name can be missing
Four common reasons, all structural:
| Reason | What to do about it |
|---|---|
| It uses a private or internal certificate authority | Nothing public will ever find it. Inventory it yourself. |
| It sits behind a private network or VPN | Correct, and out of scope for a public scan. |
| It is only covered by a wildcard certificate | *.example.com never reveals payroll.example.com. Add the name manually to your own list. |
| Your inventory exceeds the discovery cap | Hostname discovery is capped at 20,000 names. Above that, assume it is a sample. |
Discovery is not DNS brute force and does not pretend to be exhaustive enumeration.
Read the address, not just the hostname
This is where most misassigned tickets come from. Before you send a finding to someone, look at which address and port produced it.
- One hostname can resolve to several addresses, and IPv4 and IPv6 can land on entirely different infrastructure with entirely different TLS settings.
- If a CDN or reverse proxy terminates TLS, then its certificate and its cipher list are what an outside scan measures. The hop from that proxy to your origin is a separate connection needing a separate assessment. Fixing the origin will not change the report.
What is in scope
- Web: port 443 for TLS inspection, port 80 for redirect checks.
- Mail: delivery on port 25 and submission on 465 and 587, against the MX hosts for the submitted domain. An MX hostname normally stays out of the web inventory even if it also serves a website, while the submitted hostname itself stays in web scope. See email transport.
What is not in scope: an all-port inventory, anything requiring authentication, anything on a private address, and the application behind the TLS layer.
A report is a timestamp, not a live view
Opening a report link re-reads a stored result. It does not re-run anything. Submitting the same domain again may reuse an in-flight scan or hand back a recent report rather than starting fresh.
So before you use a report to prove a fix worked, check its date against your deployment time. Use the retest action rather than the home page. Fixing and retesting walks through it.