What is a subdomain takeover?

A subdomain takeover happens when a DNS record still points to a third-party resource (a storage bucket, a PaaS app, a static site host) that has since been deleted, letting an attacker claim that same resource name and serve content under the victim's own subdomain.

Which cloud services are most associated with subdomain takeovers?

Any platform where resource names are chosen by the customer and become available for reuse after deletion — object storage buckets, static site hosts, and PaaS app platforms are the most commonly cited categories, though the underlying issue is generic to any such service.

How do I know if one of my subdomains is vulnerable?

Enumerate your own subdomains, find every CNAME pointing at a third-party platform, and check whether the target still resolves to a resource you actually control — a distinctive "not found" or "no such bucket" style error on the target is the signature of an unclaimed, takeover-ready resource.

Subdomain Takeover: How a Forgotten DNS Record Becomes a Vulnerability

A subdomain takeover doesn't require breaking into anything — it exploits a DNS record nobody remembered to delete, pointing at a resource nobody owns anymore.

What It Is

A subdomain takeover happens when a DNS record — usually a CNAME — still points to an external resource (a cloud storage bucket, a hosting platform app, a static site service) that has since been deleted, while the record itself was never removed. Anyone who can claim that same resource name on the platform now controls what serves under your subdomain.

How It Happens

A team points promo.example.com at a third-party service — an object storage bucket, a PaaS app, a static site host — via CNAME
Later, that resource is deleted or the subscription lapses, but the CNAME record in DNS is left in place
The resource's name becomes available again on that platform, since the platform has no idea it's still referenced by someone else's DNS
An attacker claims the exact same resource name on the platform
Traffic to promo.example.com now reaches the attacker's resource, because the CNAME was never pointing at your domain's own infrastructure in the first place — it was always pointing at a name on someone else's platform

Why It's Effective

Content served this way runs under the victim's own domain, which lets it bypass domain-based allowlists, look legitimate in phishing links since the visible domain really is the real one, and in some cases even qualify for a valid TLS certificate for that subdomain — because the attacker genuinely does control the resource the DNS record points to.

How Attackers Find Candidates

Subdomain enumeration surfaces every CNAME pointing at third-party platforms; checking which of those targets return a distinctive "not found" or "no such bucket" error — the signature of an unclaimed resource — narrows the list to exploitable ones.

Prevention

Remove the DNS record at the same time a resource is decommissioned — this is the only complete fix, since a record with nothing legitimate behind it is the entire vulnerability. Auditing subdomains periodically, especially after any migration away from a third-party service, catches what decommissioning checklists miss.

Audit Your Own Subdomains

Find your subdomains →Next: DNS spoofing and cache poisoning →

Try it on your domain

See the theory in practice — run a Subdomain Finder for your own domain.