How to Find Subdomains of a Domain: Certificate Logs, DNS and Their Limits

To find the subdomains of a domain without touching its servers, search the Certificate Transparency (CT) logs. Every publicly trusted HTTPS certificate is recorded in these open logs together with the hostnames it covers, so a query to crt.sh or Cert Spotter for example.com returns names like mail., staging. or old-shop.example.com. Then check each name in DNS to see which still exist and where they point. Our free subdomain finder does both steps. Be aware of the limit: no outside method returns a guaranteed complete list. Only the domain’s DNS zone, visible to its owner, has that.

Ways to find subdomains, compared

Method 1: Certificate Transparency logs

Certificate authorities publish the certificates they issue to public, append-only CT logs, and browsers such as Chrome and Safari only trust publicly issued certificates that have been logged. Because a certificate lists the hostnames it is valid for, the logs are effectively a history of every name on a domain where someone turned on HTTPS.

1. Open crt.sh and search for %.example.com (the % is a wildcard, so you get all subdomains).
2. Read the “Matching Identities” column. Names in the logs are kept forever, so many will be historical.
3. For a clean list, use the JSON output and remove duplicates:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' \
  | tr 'A-Z' 'a-z' | sed 's/^\*\.//' | sort -u

%25 is the URL-encoded %. The name_value field can hold several names separated by line breaks; jq -r prints them on separate lines. crt.sh is a free community service and often answers with 502 errors or timeouts under load — it did so for us repeatedly while we wrote this article on 13 October 2026. If that happens, try later or use Cert Spotter:

curl -s 'https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names' \
  | jq -r '.[].dns_names[]' | sort -u

According to SSLMate’s API documentation, Cert Spotter returns only unexpired certificates and allows a limited number of unauthenticated queries per hour for personal or evaluation use. So crt.sh gives you history, Cert Spotter gives you what is current.

Method 2: check which subdomains are alive in DNS

A name in a certificate log only proves that a certificate was once issued. To see what exists today, ask DNS:

# does the name resolve, and to what?
dig +short staging.example.com

# is it an alias (CNAME), and to which host?
dig +short CNAME staging.example.com

# full answer: look at "status:" — NOERROR or NXDOMAIN
dig staging.example.com

# wildcard DNS test: a random name should NOT resolve
dig +short pp-test-8f3k2.example.com

• NXDOMAIN — the name no longer exists; only the old certificate is left. That is history, not a problem.
• NOERROR with an address — the subdomain is live. Make sure you still need it and that it is maintained.
• NOERROR without an A/AAAA record — the name exists but has no address (for example, only MX or TXT). Usually fine.
• A CNAME that leads to a name that does not exist — a dangling record. See the takeover section below.

If the random name in the last command resolves, the domain uses wildcard DNS: any name answers, so “it resolves” proves nothing about a specific subdomain.

Why no tool can show every subdomain

• Wildcard certificates. If services run under *.example.com, the logs contain only the asterisk, not the individual names.
• Names without public HTTPS. Hosts that only serve plain HTTP, mail-only names and internal services with certificates from a private CA never reach the CT logs.
• DNS has no “list everything” query. A resolver answers questions about names you already know. The only standard way to dump a zone is a zone transfer, and servers refuse it to strangers.
• Old names stay in the logs. The list is always a mix of current and long-gone names, which is why the DNS check matters.

Active methods: brute force and zone transfers

Active methods send queries to the target’s infrastructure. They are standard practice in security testing — on systems you own or are explicitly allowed to test.

• Dictionary brute force tries thousands of likely names (dev, api, vpn, staging…) against DNS. OWASP Amass combines open-source information gathering with active reconnaissance; subfinder sticks to passive sources only.
• Zone transfer (AXFR) is the mechanism secondary DNS servers use to copy a zone (RFC 5936). Test your own domain like this:

dig NS example.com +short
dig AXFR example.com @ns1.example.com

A correctly configured server answers “Transfer failed” or refuses. If your server returns the full zone to anyone on the internet, restrict AXFR to your secondary servers.

Dangling CNAMEs and subdomain takeover

A typical story: for a campaign someone created promo.example.com as a CNAME to example-promo.herokuapp.com. Later the app was deleted, but the DNS record stayed. If the platform lets anyone create an app (bucket, page) with the same name, an attacker can claim it and serve their own content on your subdomain, with your domain in the address bar. This is called subdomain takeover.

A dangling CNAME on its own is not proof of a vulnerability — some platforms do not let a released name be claimed again, and confirming it requires checking the platform itself. But the fix is cheap: delete the CNAME, or recreate the resource at the provider if you still need the subdomain.

What to do with the subdomains you found

1. Export the list and mark every name you did not know about.
2. Delete dangling CNAMEs and records for old test environments and finished campaigns.
3. Put admin panels, staging and internal tools behind authentication or an IP allowlist, and do not leave them on outdated CMS versions.
4. Check the important live subdomains: certificate validity with the SSL checker, records with DNS lookup, and a passive check for malicious code and outdated software with the website security scanner.
5. Repeat the search periodically: every new certificate adds names to the logs.

How to find subdomains with PromoPilot

Enter a domain in the subdomain finder. It takes the names from crt.sh (the full certificate history); if crt.sh does not respond, it falls back to Cert Spotter (current certificates only) and says so. The name list is cached for 24 hours. Then:

• it normalises names (lower case, without *., only the domain and its subdomains);
• checks up to 300 names in DNS — those with the newest certificates first — through Cloudflare’s public DNS-over-HTTPS resolver with Google as a fallback: A records, then AAAA for names without A;
• shows the status of each name (in DNS, not in DNS, no A/AAAA, dangling CNAME), the CNAME chain and when the newest certificate expires;
• tests for wildcard DNS with a random name and marks affected rows, and warns when wildcard certificates were found;
• names the service behind a dangling CNAME when it is on a list of platforms where takeover is possible (Amazon S3, Azure, Heroku, GitHub Pages, Netlify, Shopify and others);
• lets you filter the table and download it as CSV.

Limits: 15 searches a day without an account, 45 with a free account, no daily limit on Pro, and at most 6 searches a minute.

What the tool does not do

• No dictionary brute force, no port scanning and no HTTP requests to the hosts it finds. That is why it can flag a takeover risk but cannot confirm it.
• It sees only names that had a public certificate. Names hidden behind a wildcard certificate or never served over HTTPS will not appear.
• For domains with very many certificates, the list is capped at 5,000 unique names, and DNS is checked for 300 of them per run.

Related reading

• SSL certificate check — validity, chain and protocols.
• Checking DNS records — A, CNAME, MX, TXT and what they mean.
• How to check if a website is safe — the wider security checklist.