How to Find All Subdomains of a Domain (5 Methods, Free)

Just want the list? Run the Subdomain Finder — it applies all five methods below in one scan. Auch auf Deutsch: Subdomains herausfinden.

Every domain is bigger than it looks. Behind example.com there's usually a sprawl of subdomains — mail.example.com, vpn.example.com, staging.example.com, api.example.com — and many of them were spun up years ago and quietly forgotten. Finding all the subdomains of a domain matters whether you're auditing your own attack surface, doing authorized security testing, or researching a target's infrastructure.

The catch: there is no single DNS query that returns "every subdomain." DNS doesn't work that way. Instead, you combine a few complementary techniques, each of which catches subdomains the others miss.

This guide walks through five practical methods, from the fastest (paste a domain into a tool) to the most thorough (combining passive and active discovery). If you just want results now, run our Subdomain Finder and read on to understand what it's doing under the hood.

Why "Just Ask DNS" Doesn't Work

The obvious idea — ask the domain's DNS server for a list of all its records — almost never works. That capability is a DNS zone transfer (AXFR), and for good reason nearly every nameserver on the internet refuses it from strangers. A misconfigured server that does allow public zone transfers is a finding in itself, but you can't rely on it.

So subdomain discovery becomes a game of gathering evidence from many sources and merging the results. The five methods below are the ones that actually find things.

Method 1: Certificate Transparency Logs (the highest-signal source)

Every time a certificate authority issues a TLS certificate, it logs it to public, append-only Certificate Transparency (CT) logs. Because almost every subdomain that has ever served HTTPS needed a certificate, those logs are a goldmine of real, confirmed subdomains — including internal-sounding ones like dev., jenkins., or vpn..

CT logs are:

• Passive — you're reading public records, not touching the target.
• Historical — they surface subdomains that existed even if they're offline now.
• Accurate — these are names that genuinely had certificates issued.

The trade-off is that CT only shows names that were put on a certificate. A subdomain that never served HTTPS (or hid behind a wildcard *.example.com cert) won't appear.

Our Subdomain Finder queries CT logs for you and resolves each name it finds, surfacing the ones that are still live — no manual log searching required.

Method 2: DNS Brute-Force (guessing common names)

Brute-forcing means taking a wordlist of common subdomain names — www, mail, smtp, ftp, api, dev, test, staging, vpn, portal, admin, cdn, blog — and checking whether each one resolves.

www.example.com      → 203.0.113.10   ✅ exists
mail.example.com     → 203.0.113.25   ✅ exists
staging.example.com  → NXDOMAIN        ❌ doesn't exist
api.example.com      → 203.0.113.40   ✅ exists

This is active discovery — you're sending DNS queries for each guess. Its strength is finding live subdomains that never appeared in a certificate log. Its weakness is that it only finds names on your wordlist; a subdomain called q3-migration-temp will never be guessed.

Our Subdomain Finder combines certificate transparency logs (Method 1) with a curated list of the most common subdomain names, then resolves every candidate — so you get the high-value hits fast, without running a scanner yourself.

Method 3: Search Engines and OSINT Operators

Search engines have already crawled a lot of a domain's subdomains. You can pull them out with a site operator:

site:example.com -www

The -www removes the main site so subdomains rise to the top. Combine this with public OSINT sources — Shodan, VirusTotal, and DNS aggregators — that keep their own indexes of observed hostnames. Each source has a slightly different view, which is exactly why combining them works.

Method 4: Mine the Domain's Own DNS Records

Existing DNS records point at subdomains you might otherwise miss:

• MX records name mail hosts (e.g. mail.example.com, mx1.example.com). Check them with our MX / DNS records guide.
• CNAME and A records referenced in the site's HTML, JavaScript, and CSS often point to cdn., static., assets., or api. subdomains.
• TXT and SPF records frequently include: other hostnames — validate them with the SPF checker.
• NS records can reveal delegated subdomains run by a different team.

A quick pass over a domain's published records with a DNS health check surfaces a surprising number of hostnames.

Method 5: Combine Everything (the thorough approach)

Serious subdomain enumeration merges passive sources (CT logs, search engines, OSINT feeds — quiet and historical) with active verification (DNS resolution to confirm what's actually live right now). The workflow looks like this:

1. Pull candidate names from CT logs and OSINT (Methods 1 & 3).
2. Add brute-force guesses for common names (Method 2).
3. Extract hostnames from the domain's own records and page source (Method 4).
4. De-duplicate the combined list.
5. Resolve each candidate to confirm which are live and where they point.

That merge-and-verify loop is exactly what a good subdomain finder automates.

How to Read Your Results

Once you have a list, a few things are worth checking for each subdomain:

Find Your Subdomains Now

You don't need to run a command-line scanner to get started:

1. Open the Subdomain Finder.
2. Enter your domain (e.g. example.com).
3. Review the discovered subdomains and where each one resolves.
4. Cross-check anything surprising against your DNS provider, and remove stale or dangling records.

Frequently Asked Questions

How do I find all subdomains of a domain? Combine certificate transparency logs, DNS brute-forcing of common names, search-engine operators, and the domain's own DNS records, then resolve each candidate to confirm it's live. A subdomain finder automates this.

Can I find subdomains for free? Yes. Certificate transparency logs and search-engine operators are free, and our subdomain finder is free to use.

Is finding subdomains legal? Reading public sources (CT logs, search engines) is generally fine. Actively scanning infrastructure you don't own or have permission to test may not be — stick to your own domains or authorized engagements.

Why don't all subdomains show up? No single method is complete. CT logs miss names that never had a certificate; brute-force misses unusual names; search engines miss uncrawled hosts. That's why you combine sources.

Key Takeaways

• ✅ There's no single query for "all subdomains" — DNS zone transfers are (rightly) blocked.
• ✅ Certificate transparency logs are the highest-signal passive source.
• ✅ DNS brute-force catches live names that never appeared on a certificate.
• ✅ The domain's own MX/CNAME/SPF/NS records reveal more hostnames.
• ✅ Combine passive + active discovery, de-duplicate, then resolve to confirm.
• ✅ Watch for wildcard DNS and dangling subdomains that risk takeover.

Auditing your wider DNS footprint too? Start with a DNS health check and read DNS TXT records: why one typo breaks everything.