Subdomain Finder
Find subdomains observed for a domain, each with the dates it was first and last seen, so you can tell live infrastructure from historical records.
Enter the root domain — example.com, not mail.example.com.
Related tools
All Network tools →This tool queries an external service to answer your request. Only the value you enter — such as a domain or IP address — is sent. Your other data stays on your device.
This tool reads public records — DNS, WHOIS and certificate data that registries and servers publish openly. It sends nothing to the host you enter and changes nothing there. Use it on infrastructure you own or are authorised to look into.
About the Subdomain Finder
List the subdomains that have been observed for a domain, each with the date it was first seen and the date it was last seen. Those two dates are what make the result useful rather than merely long: a name last seen four years ago is history, and a name last seen yesterday is live infrastructure.
The usual reason to run this on your own domain is that organisations lose track of what they have. A staging server from a project that shipped in 2021, a legacy admin panel nobody remembers, a marketing microsite built by an agency that no longer works for you — these keep resolving, keep running whatever software they were left with, and keep being reachable long after anyone stopped patching them. They are found by attackers precisely the same way they are found here. Seeing your own list is usually a mildly uncomfortable experience and a productive one.
Discovery works mainly from certificate transparency logs, which are public and permanent by design. Every time a certificate authority issues a certificate it must publish the names in it to an append-only public log, so a subdomain that has ever had a TLS certificate is a matter of public record from that moment onwards. This has an important consequence people often have not thought through: a subdomain is not a secret. Naming something internal-admin.example.com and not linking to it hides it from nobody, because the certificate you issued for it announced it to the world.
Equally, the list is not exhaustive, and treating it as one would be a mistake. A subdomain that has never held a public certificate and has never been observed may be entirely absent. Nothing found means nothing was seen in the sources searched — never that nothing exists.
Results are paginated, and each page is a separate lookup. This tool asks before fetching another page rather than quietly walking the whole list, so a domain with thousands of subdomains does not turn one click into forty.
How to use the Subdomain Finder
-
Enter the root domain
Type the root — example.com, not mail.example.com. Discovery works down from the root, so giving it a subdomain narrows the search rather than widening it.
-
Choose what to show
All is the right default. Active only filters to hosts recently observed responding, which is useful when you are auditing what is live rather than what has ever existed.
-
Run the search
Complete the verification check and press Find subdomains. The first page of results comes back with the total count.
-
Read the dates before acting
Last seen is the column that matters. A recent date means live infrastructure worth checking; a date years old usually means a record that outlived the server behind it.
Frequently asked questions
Is it legal to look up someone else's subdomains?
Yes. Everything shown here comes from public records — principally certificate transparency logs, which certificate authorities are required to publish. No connection is made to any of the hosts and nothing is scanned or probed. It is the same category of activity as reading WHOIS. What you then do with the list is a separate question: connecting to systems you do not own or have permission to test is not covered by the fact that you found their names publicly.
Why does it show subdomains that no longer exist?
Because certificate transparency logs are append-only and permanent. A certificate issued for staging.example.com in 2019 is in the public record for ever, even if the host was decommissioned the following week. That is why every result carries a last-seen date — it is the field that separates live infrastructure from a historical entry, and it is worth reading before you conclude anything.
I found a subdomain I did not know about. What should I do?
Establish what it is before you touch it. Check the last-seen date, look up where it points with our DNS tool, and check whether its certificate is still valid. Forgotten staging servers and legacy admin panels are the usual finds, and they matter because they are typically running software that stopped being patched when everyone stopped thinking about them. Either bring it back under maintenance or remove the DNS record; leaving it is the one option with no upside.
Does an empty result mean the domain has no subdomains?
No, and this distinction is important. It means none were observed in the sources searched. A subdomain that has never been issued a public TLS certificate and has never been recorded may not appear at all. This tool is good for finding what is publicly known and is not a guarantee of completeness, so do not use an empty result as evidence that nothing is there.
Why does each page cost a separate lookup?
Because the data provider charges per page, and we would rather show you that than hide it. A domain with several thousand subdomains would be dozens of billed calls if we fetched everything automatically, all from one button press. Asking before each page keeps the choice with the person making it.
Can I hide a subdomain from tools like this?
Not once it has had a public certificate — that record is permanent and public by design. The practical approach is to stop treating subdomain names as a security measure at all, because they never were one. Put access control in front of anything sensitive, and if a name genuinely must not be publicly known, use a private DNS zone that never receives a public certificate.