Subdomain finder FAQ

What is a subdomain finder?

A subdomain finder is a tool that lists every subdomain belonging to a root domain, such as api.example.com, staging.example.com and mail.example.com. Most modern subdomain finders read public Certificate Transparency logs, which are published records of every TLS certificate issued. Because those logs are public, anyone can look up which hostnames a company has issued certificates for, without scanning or touching the target's systems.

Is it legal to find someone's subdomains?

Yes, in the large majority of cases. Subdomain finders read public, published data: Certificate Transparency logs are designed to be publicly searchable and are consumed by browsers, antivirus vendors and search engines alike. The legal position depends on your jurisdiction and intent. Actively scanning, probing or attempting to access a system you do not own is a different matter and can be unlawful. Use these results for securing your own infrastructure, or for authorised security testing, and check the rules of any bug bounty programme before testing a system you do not own.

Where does the data come from?

Results come from crt.name, a public search interface over Certificate Transparency logs. Before a publicly trusted TLS certificate can be issued, its domain names must be submitted to these logs, which are append-only public records. We read that data and nothing else. We do not scan, probe, or connect to the subdomains we list, and we do not collect the IP addresses or other infrastructure behind them.

Why do results include old or broken subdomains?

A Certificate Transparency log records what was requested at issuance time, and entries are never removed. If a team issued a certificate for staging.example.com, later deleted the host, and issued no new certificate with revocation at the hostname level, that name stays in the log indefinitely. This is why a subdomain finder often surfaces hosts that no longer resolve. It is also exactly why the tool is useful: forgotten hosts are a common and genuine source of exposure.

Will this find every subdomain?

No tool can, because there is no complete public list. Subdomains that never received a publicly trusted TLS certificate are invisible to this method, as are internal-only and private-network hosts. Some names are also hidden behind wildcard certificates, which cover arbitrary subdomains under a domain without each one appearing in the log. Treat the results as a strong starting point and a list of publicly attested hostnames, not a complete inventory. For full coverage, combine this with your own DNS zone data and internal inventories.

How do I remove a subdomain from the results?

You cannot remove entries from a Certificate Transparency log; that is the point of the system, and it is why the log is a trustworthy record. What you can do is make the hostname stop being a useful finding. Delete the DNS record and retire the host, and request a new certificate for your wildcard that excludes the name if you rely on wildcard coverage. Then make sure the orphaned host cannot be claimed by someone else: if a sub-delegated zone still exists, remove it, so the name cannot be re-registered or pointed at an attacker's server. If the host is genuinely dead but its DNS still resolves to a provider you no longer use, point it somewhere harmless or remove the record entirely.

Why does a domain return no results?

It usually means no publicly trusted TLS certificate has ever been issued for that domain or any of its subdomains, which is common for internal, very new, or purely non-web services. It can also mean the certificate is private or self-signed, or was issued under a different, higher-level domain name. Double-check the spelling, and try the registrable root domain rather than a full subdomain path.

What should I do with the subdomains I find?

Start with anything that looks abandoned: dev, staging, test, old, beta, admin, internal, backup, v1, legacy. Check whether each one still resolves and is still maintained. An unmaintained subdomain that resolves to a live host is a real risk, because a lapsed CNAME or dangling DNS record can be claimed by an attacker. Remove DNS records for hosts you have retired, and take down any host still running unpatched software or an outdated admin panel.

Do I need an API key or an account?

No. There is nothing to sign up for and no key to configure. Type a domain into the search box and the results appear immediately. That is a deliberate choice: this is a public-data lookup, and a wall of signup would add nothing to it.

Still have a question?

If something here is unclear, the mechanism page explains the underlying technology in detail, and the glossary covers what the subdomain names you find actually mean.