Skip to content

Free tool · Public CT logs

Every subdomain,
hiding in plain sight

Every TLS certificate is logged publicly — and each one names the hostnames it covers. Read those logs and a domain's whole subdomain map falls out, no scanning required.

Queries public Certificate Transparency logs (every TLS certificate is logged by law of the ecosystem). Because certificates list every hostname they cover, this also surfaces subdomains.

What Certificate Transparency reveals

Your forgotten subdomains

staging., old-app., vpn., admin. — anything that ever got a certificate is in the logs forever. Attackers read this first; you should read it before they do.

Your certificate history

Which CAs you've used, when certificates were issued and when they expire — a timeline of your TLS hygiene without touching a single server.

Shadow IT and acquisitions

Certificates issued by teams or vendors you've lost track of show up here, often the first sign of infrastructure nobody's monitoring.

Sending-subdomain reputation

A clean, consistent certificate history on your mail subdomains is one more quiet signal to receivers that you're an established, legitimate sender.

Questions, answered honestly

How does this find subdomains without scanning anything?

Every publicly-trusted TLS certificate must be logged in public Certificate Transparency (CT) logs — it's how the web keeps certificate authorities honest. Those certificates list every hostname they cover in their SAN field. So by reading the CT logs for a domain, we can see every subdomain anyone ever requested a certificate for, with zero scanning or guessing.

Why would a cold-email sender care about CT logs?

Two reasons. Security: attackers use exactly this technique to map your attack surface, and forgotten staging/dev/admin subdomains are sitting in the logs in plain sight. Deliverability: dedicated sending subdomains (mail., send., go.) with a clean certificate history reinforce that you're a real, organized operation rather than a fly-by-night sender.

Is this the same as an SSL checker?

No, and the distinction is honest: a live SSL checker connects to a server and inspects the certificate it's serving right now — which needs a real TLS handshake a browser can't make to arbitrary hosts. This reads the public record of every certificate ever issued for the domain. It's certificate history and subdomain discovery, not a live-handshake test.

What does a wildcard entry (*.example.com) mean?

A wildcard certificate covers every direct subdomain at once without naming them, so the owner doesn't have to log each one. It's convenient but it also means a single key protects everything — and if that key leaks, every subdomain is exposed. The tool tags wildcard entries so you can see how much is hidden behind them.

Are the results complete?

Close, but not guaranteed. CT logging is near-universal for modern public certificates, so coverage is excellent — but certificates from before CT became mandatory, or private/internal CAs, won't appear. Treat it as 'everything that touched the public web', which for reconnaissance and audit is the part that matters.

Know your surface. Then send from it cleanly.

Norbelys helps you run cold email on dedicated sending domains and subdomains the right way — authenticated, warmed, and monitored — so your infrastructure is an asset, not an exposure.

Start sending

From $29/mo · Cancel anytime