What Is a Subdomain Takeover (and How to Check If You're Exposed)

5 min readExamfy Software

You spun up a marketing microsite on a hosting platform two years ago, pointed promo.example.com at it with a CNAME, and later deleted the site. You never touched the DNS record — it's just an alias pointing at a hostname that no longer exists, so nothing loads. Harmless, surely.

Not quite. If the platform lets anyone claim that hostname again, whoever claims it now controls a page served from your domain. That's a subdomain takeover, and it's one of the more common ways a company ends up hosting content it didn't write.

Why a dead record is worse than no record

The mechanics are simple, which is why this keeps happening:

  1. You point promo.example.com at a third-party service with a CNAME — promo.example.com → yourapp.somehost.com.
  2. You stop paying for, or delete, the resource on that service. The hostname yourapp.somehost.com becomes unclaimed.
  3. You never remove the CNAME. Your DNS still says "for promo.example.com, go ask somehost.com."
  4. Someone signs up for that service and claims yourapp.somehost.com — often free, often in minutes.
  5. Their content now answers for promo.example.com.

The attacker never touches your registrar, your DNS provider, or your servers. They don't need to. You left a signpost pointing at an empty plot, and they built on it.

What makes this genuinely damaging is that it's your domain doing the talking. Browsers show your name. Any cookie scoped to .example.com may be readable from that subdomain. Your reputation carries the phishing page, the SEO spam, or the malware. And because most organizations don't have a list of their own subdomains, it can run for months.

The two conditions you're looking for

A subdomain is exposed when both are true:

  • A DNS record still points somewhere, and
  • The target is unclaimed and claimable by a stranger.

The second condition is what separates a real risk from harmless clutter. A CNAME pointing at a service that lets anyone register the same hostname is dangerous; one pointing at an IP address you no longer own is a different (usually lesser) problem; one pointing at a decommissioned internal host that nobody else can claim is mostly just untidy.

How to find your exposure

Step 1 — get the list of subdomains you actually have

You can't audit what you can't see. Most teams badly underestimate this: the microsites, the staging hosts, the tool a former colleague set up.

The fastest way is our free subdomain finder, which reads public Certificate Transparency logs — every publicly-trusted certificate ever issued for your domain is recorded there along with the hostnames it covers. It's passive, so nothing is sent to your infrastructure. There's a fuller explanation of the method and its limits in how to find all subdomains of a domain.

Step 2 — pay attention to the ones marked "No DNS"

Here's where the tool earns its keep for this particular job. For each subdomain it finds, it does a live DNS lookup and marks it Live or No DNS.

"No DNS" is your shortlist. It means a certificate was issued for that hostname at some point — so it was a real, deployed thing — but it doesn't resolve today. That's exactly the fingerprint of a service that was torn down. Some of those are completely clean (the DNS record was removed properly, which is the correct outcome). Others are the dangerous case: the record still exists but points at a target that has itself vanished.

Treat "No DNS" as worth inspecting, not as confirmed vulnerable. The tool tells you where to look; it doesn't decide for you.

Step 3 — check what the record actually points at

For each candidate, look up its DNS records — our WHOIS & DNS lookup shows the CNAME, A and AAAA for a hostname. The question you're answering:

  • Is there still a CNAME? If the record is gone entirely, you're fine — that's cleanup done right.
  • Where does it point? If it points at a third-party platform's hostname, check whether that resource still exists on that platform. If it doesn't, and the platform allows re-registering the name, you have a live exposure.
  • Does the platform have a claim check? Many services now require you to prove domain ownership before serving traffic for a custom hostname, which closes the hole. Many still don't.

If you're unsure how to read what comes back, how to read a WHOIS record and your DNS settings walks through each record type.

Fixing it, and keeping it fixed

The fix is almost always one action: delete the DNS record. Not the certificate, not the account — the dangling record. If a subdomain isn't serving anything, it shouldn't have a record pointing anywhere.

That gives you a rule worth adopting: decommissioning a service includes removing its DNS. Most takeovers exist because teardown stops at "delete the app" and never reaches "delete the CNAME". Put DNS removal in the same checklist as cancelling the subscription.

A few habits that reduce the surface:

  • Prefer specific records over wildcards. A *.example.com record means every conceivable subdomain resolves somewhere, which makes this class of problem much harder to reason about.
  • Set a CAA record. It doesn't prevent takeover, but it limits which certificate authorities can issue for your domain, narrowing what an attacker can do with a name they control.
  • Keep an inventory. Even a plain list of subdomains and what they're for turns this from an investigation into a five-minute check.

The part a one-time audit misses

Auditing today tells you about today. The exposure you'll actually get bitten by is the one created next quarter — a new microsite, a new vendor trial, a service someone cancels without telling anyone. Subdomains and their certificates keep appearing, and dangling records are created by ordinary, well-intentioned cleanup.

That's the argument for watching rather than auditing. DomainChest monitors Certificate Transparency logs for your domains, so when a certificate is issued for a subdomain — including one you didn't expect — you hear about it, along with changes to your DNS records and the expiry clocks on the domain and its certificates. There's more on the DNS change monitoring page.

Start by listing your subdomains and looking hard at anything marked "No DNS". That list is usually shorter than people fear, and more interesting than they expect.

Track every domain and SSL certificate you own

Store your domains in a chest, so you never forget one again.

Start free — 3 domains