Every domain is bigger than it looks. Behind example.com there may be a staging server, an old campaign microsite, a VPN portal and a test login page that nobody has touched in two years. A subdomain finder is how you discover them. A good subdomain finder turns a vague idea of your attack surface into a concrete list you can review, question and clean up.

This guide shows you how to find out subdomains of a domain using certificate transparency logs, DNS records, search engines, command-line tools and online scanners. You will see how each method works, where it falls short and how to combine them for better coverage. It is written for MSSPs, MDR providers, penetration testers, bug bounty hunters and IT teams who want a complete answer without opening ten other tabs.One rule before we start: only scan domains you own or have written permission to test.

What Is a Subdomain Finder?

A subdomain finder is a tool or process that discovers the subdomains attached to a root domain, such as mail.example.com or staging.example.com. It pulls names from public data sources like DNS records and certificate transparency logs, then lists the hostnames it finds so you can review them.

A subdomain is the part that sits to the left of the main domain. In blog.example.com, "blog" is the subdomain, "example" is the domain name and ".com" is the top-level domain. Each subdomain can point to a different server, run different software and carry its own security certificate.

You may also see the same idea called subdomain lookup, subdomain checker, subdomain search, or subdomain enumeration. The terms overlap heavily. Enumeration is the technical term security teams use for the full process of listing and validating the hostnames under a domain. A subdomain finder is the tool that does the work.

People use a subdomain finder for three main reasons:

• To map an organization's external footprint before a penetration test or bug bounty engagement.

• To find forgotten hosts that should have been retired.

• To research how a competitor structures its web presence.

How a Subdomain Finder Works

A subdomain finder works by combining several public data sources and checks, since no single record lists every subdomain a domain has. Most tools query certificate logs, public DNS data, search engines and common naming patterns, then merge and deduplicate the results.

Here is what happens behind the scenes.

Certificate transparency logs

When a certificate authority issues a publicly trusted TLS certificate, the certificate is typically recorded in public certificate transparency (CT) logs. The mechanism is described in RFC 6962 from the IETF. Each certificate lists the hostnames it covers, so searching the logs for a domain reveals subdomains that have ever had a certificate. This is one of the richest sources available because it is public and searchable.

Public DNS records

DNS is the system that maps names to addresses. A finder can look at records tied to a domain, such as A, AAAA, CNAME, MX and NS records, to learn which hostnames exist. Passive DNS datasets, which collect historical lookups over time, can also reveal names that no longer appear in current records.

Search engines and OSINT

Search engines index pages on many subdomains. Operators such as site: let you list indexed hostnames. Other open-source intelligence (OSINT) sources include code repositories, archived pages and public datasets that mention hostnames in configuration files or documentation.

Known naming patterns and brute-forcing

Teams tend to name hosts predictably: dev, test, staging, api, vpn, mail, portal and so on. A finder can try a wordlist of common names against the domain and see which ones resolve. This is called brute-forcing and it can find subdomains that never appeared in a certificate or a search index.

Wildcard DNS

Wildcard DNS can confuse enumeration. If a domain has a wildcard record, every possible name resolves, even random ones like qzx81k.example.com. A careful finder tests for this first by resolving a name that cannot exist. If it resolves, the tool must filter results or it will report thousands of false positives. Wildcard behavior is described in RFC 4592.

Passive vs. Active Subdomain Enumeration

Passive enumeration collects subdomains from third-party data without sending requests to the target's own servers. Active enumeration directly queries the target's DNS servers or hosts, for example by brute-forcing names. Passive is quieter and safer to run. Active is more thorough but leaves traces.

Here is how the two approaches compare in practice.

Passive enumeration uses certificate logs, passive DNS datasets, search engines and archives. It is fast, low-risk and does not alert the target. Its weakness is coverage: a subdomain that never received a public certificate, was never indexed and never appeared in a dataset will not show up.

Active enumeration resolves guessed names, attempts zone transfers (almost always refused by modern servers) and probes discovered hosts. It can find internal-style names that passive sources miss. The cost is noise. Active scans generate traffic that logs and monitoring tools can detect and they require clear authorization.

Most professionals start passive and move to active only when the scope allows it. According to the Mispar tool page, its discovery uses public DNS records only and does not touch the target server directly, which places it on the passive-friendly side of this spectrum.

How to Find Subdomains of a Domain (Step by Step)

You can find subdomains of a domain by running a free online scanner, searching certificate logs, using Google operators and running command-line tools, then validating which results are live. Combining two or three methods gives far better coverage than any one alone.

Step 1: Confirm your scope

Write down the root domain and get authorization if it is not yours. For client work, note which assets are in scope. This protects you legally and keeps the results focused.

Step 2: Run an online subdomain finder

The fastest start is an online tool with no installation. Enter the root domain and let the tool query its sources. The free Mispar tool lets you find out subdomains of a domain by checking public DNS records, certificate logs and known naming patterns and it needs no signup. You can run it from any browser, which makes it handy for quick client checks.

Treat the output as a starting list. As the tool page itself notes, no scanner finds every subdomain.

Step 3: Search certificate transparency logs directly

Public CT search sites let you query the logs yourself. On crt.sh, search for your domain with a leading wildcard, written as %.example.com. You will see certificates issued for the domain and the hostnames they cover. Names in the results include current and expired certificates, so some hosts may be gone. Wildcard certificates (for example, *.example.com) tell you a wildcard is in use but do not list individual hosts.

Step 4: Use Google dorks

Search engines can reveal indexed subdomains with no tools at all. Use the site: operator with your root domain and exclude the www host. Then exclude each hostname you have already found to uncover new ones. Keep adding exclusions as you go. This works best for subdomains that host public web pages.

Step 5: Run command-line enumeration tools

If you use Kali Linux or any Linux or macOS terminal, several tools automate the process. Subfinder, from ProjectDiscovery, focuses on passive sources. Amass, an OWASP project, supports both passive and active modes. Sublist3r is another common choice for quick passive lookups. Most of these tools can write results to a file, which you can merge across tools and deduplicate. Check each tool's documentation for the current options, because flags change between versions.

Step 6: Check DNS records manually (including on Windows)

You can find subdomains of a domain in Windows using nslookup, though it will not list them all. It is best for checking names you already suspect. You can also look up the name server, mail and text records of the domain, which often mention other hostnames.

On Linux or macOS, dig does the same job. Some people try a zone transfer, but properly configured servers refuse it, so do not rely on it.

Step 7: Brute-force with a wordlist (where allowed)

If your scope permits active testing, resolve a wordlist of common names against the domain. A simple script, for example in Python with the dnspython library, can try each word from a list in front of the domain and record which names resolve.

Real wordlists contain thousands of entries and need rate limiting. Always check for wildcard DNS first by resolving a random string. If it resolves, filter those results.

Step 8: Validate and organize the results

A raw list is only half the job. Merge results from every method, remove duplicates and check which hosts respond. A tool such as https can probe a list for live web services. Then sort the hosts into groups: expected and owned, unknown and decommission candidates.

Why Security Teams and MSSPs Need a Subdomain Finder

Security teams need a subdomain finder because you cannot protect hosts you do not know exist. Forgotten staging servers, old marketing pages and test environments are easy to lose track of and attackers look for exactly those assets because they are less likely to be patched or monitored.

For MSSPs and MDR providers, the value is even more practical. You manage many client environments and each one has a different history of acquisitions, agencies, campaigns and migrations. A repeatable subdomain check gives you a consistent starting point for every client onboarding and every quarterly review.

Here is where a subdomain finder fits into daily work:

• Attack surface management. Subdomains are part of the external surface. Listing them is step one of any exposure review.

• Penetration testing. Reconnaissance almost always begins with enumeration. More hosts found means more of the target gets tested.

• Bug bounty hunting. Hunters often find issues on lesser-known hosts that other researchers skip.

• Shadow IT discovery. Teams sometimes launch services on a new subdomain without telling IT. Enumeration surfaces them.

• Competitor and market research. Subdomains can show product lines, regional sites and support portals.

• Client prospecting and reporting. A clear list of unexpected hosts makes a concrete, understandable point in a client conversation.

Subdomain Takeover Risks

A subdomain takeover happens when a subdomain's DNS record still points to an external service that is no longer in use and an attacker claims that service. The attacker then controls content served on your subdomain. Regular enumeration and DNS cleanup prevent most of these cases.

The typical pattern looks like this. A team creates app.example.com and points it with a CNAME record to a third-party hosting platform. Later, the team cancels the platform account but forgets to delete the DNS record. The subdomain now points at an unclaimed resource. If the platform lets anyone register that resource name, an attacker can register it and serve content under your domain.

The impact can include phishing pages that carry your brand, cookie theft in some configurations and reputational harm. OWASP's Web Security Testing Guide includes a dedicated test for this issue, which shows how established it is in security testing.

To check for takeover risk:

1. Enumerate all subdomains.

2. Look at the CNAME target for each one.

3. Test whether the target service still exists and is controlled by you.

4. Delete DNS records for anything retired.

Key Features to Look For in a Subdomain Finder

The best subdomain finder for your needs combines several data sources, handles wildcard DNS and makes results easy to review. Which features matter most depends on whether you want a quick check, a deep assessment, or an ongoing process.

Multiple data sources

A tool that only checks one source will miss hosts. Look for one that uses certificate logs, public DNS records and naming patterns together. The Mispar scanner lists exactly these three sources on its page.

Passive-first behavior

For routine checks, a tool that uses public information and does not touch the target server is easier to use safely. Check the tool's description to confirm how it works.

Clear limits

Honest tools say what they cannot do. A finder that claims to find every subdomain is overstating its reach. Prefer tools that state their coverage plainly.

No-friction access

For quick lookups, free access without a signup saves time. Online tools run from any browser, while command-line tools need setup but give you more control and scripting.

Wildcard handling and deduplication

Good tools detect wildcard DNS and clean up duplicate names so you are not wading through noise.

Validation of live hosts

Finding a name is not the same as finding a running service. Pairing discovery with a live check tells you what actually responds.

Fit for repeated use

New subdomains appear whenever a team launches a campaign page or a test environment. A tool or workflow that you can rerun easily beats a one-time audit.

Free vs. Paid Subdomain Finder Tools

Free subdomain finder tools are enough for most one-off checks, small scopes and learning. Paid platforms usually add scheduled monitoring, larger historical datasets, team features and reporting. Which one you need depends on scale and how often you must repeat the work.

Free options include online scanners, CT search sites and open-source tools such as Subfinder and Amass. They cost nothing to use, though open-source tools take time to set up and tune. Online scanners such as the Mispar page are free and need no signup, according to the tool page.

Paid products make sense when you manage many domains, need alerts when new hosts appear, or must produce client-ready reports. Prices change and vary by vendor, so check each vendor's current pricing page before deciding.

A sensible approach is to start free, learn what you actually need and only pay when repetition or scale justifies it.

Comparison Table: Ways to Find Subdomains

Each method below has a different mix of speed, depth and effort. Use it to decide which combination suits your task.

Common Mistakes When Enumerating Subdomains

Most failures in subdomain discovery come from relying on one source, trusting raw results, or skipping authorization. Avoiding these mistakes makes your list more accurate and your work safer.

• Using only one method. Certificate logs, search engines and DNS each see different parts of the picture. Combine at least two.

• Ignoring wildcard DNS. Without a wildcard test, brute-force results can be mostly fake.

• Treating the list as complete. No tool finds everything. Use the result as a starting point and keep adding sources.

• Not validating hosts. A name from an old certificate may point nowhere. Probe before you report.

• Forgetting expired data. CT logs include expired certificates, so some listed hosts no longer exist. That is useful history, but it is not a live inventory.

• Scanning without permission. Even passive work should stay within agreed scope. Active methods need explicit authorization.

• Running it once. New subdomains appear constantly. Many teams check monthly or after a major launch.

• Not acting on findings. A list that nobody reviews changes nothing. Assign owners and decommission what is not needed.

Interesting Facts About Subdomains and Enumeration

These facts come from standards bodies and security frameworks. The source type is named for each so you can verify them directly.

1. Certificate transparency is defined in an IETF standard, RFC 6962. It describes public, append-only logs of issued certificates, which is why CT search is such a reliable discovery source.

2. Google's Chrome team has required certificate transparency for newly issued publicly trusted certificates since 2018, according to Chromium project policy. As a result, most publicly trusted HTTPS hostnames leave a public trace.

3. The DNS specification (RFC 1035) limits a single label to 63 characters and a full domain name to 255 characters, so every subdomain must fit inside those limits.

4. Wildcard DNS behavior is described in RFC 4592. It is a normal feature, but it makes naive brute-forcing unreliable unless the tool tests for it.

5. OWASP's Web Security Testing Guide includes a specific test for subdomain takeover and OWASP also maintains the Amass project for enumeration and attack surface mapping.

6. The MITRE ATT&CK framework lists searching public certificate data as a reconnaissance technique. The same public data that helps defenders also helps attackers, which is why checking it yourself matters.

Conclusion

Finding every subdomain of a domain is the first step in understanding what you actually have exposed. A reliable subdomain finder gives you a quick, repeatable way to list hosts from public DNS records and certificate logs and combining it with search operators, command-line tools and live checks fills in much of what any single source misses. No method is complete, so treat each result as a starting point, validate what you find and review it regularly.If you need a fast, free check before a client call or a test, try the Mispar subdomain scanner. If you are an MSSP looking to extend monitoring beyond exposed hosts, you can learn more about the platform at Mispar.

Frequently Asked Questions (FAQs)

How do I find all subdomains of a domain?

Run the domain through a subdomain finder, then add certificate transparency search, Google operators and a command-line tool such as Subfinder or Amass. Merge the results, remove duplicates and probe each host to see which are live. No single method finds everything, so combine at least two.

Is a free subdomain finder accurate?

A free subdomain finder is accurate for the hosts it reports, but it will not report every subdomain. Subdomains missing from certificate logs and public DNS and not using a common name, may not appear. Use the result as a starting point and cross-check it with other sources.

What is the difference between passive and active subdomain enumeration?

Passive enumeration collects names from third-party data such as certificate logs, passive DNS and search engines, without querying the target's servers. Active enumeration directly queries the target's DNS or hosts, for example by brute-forcing names. Passive is quieter, while active is more thorough but needs authorization.

How do I find hidden subdomains?

Subdomains are rarely truly hidden. They are usually forgotten. Certificate logs and public DNS records often reveal old staging, test and internal-named hosts and a wordlist-based brute-force can reveal predictable names. Checking these sources regularly is the most reliable approach.

Can I find subdomains without any tools?

Yes. Use the Google search operator site:example.com -www to see indexed subdomains and search crt.sh for %.example.com to see hostnames from certificates. On Windows, nslookup can verify individual names, though it cannot list them all.

Is it legal to run a subdomain finder against any domain?

Passive discovery uses public information, but you should still get authorization before scanning infrastructure you do not manage. Active methods such as brute-forcing require explicit permission. When in doubt, confirm scope in writing first.