A subdomain takeover happens when a CNAME record on your domain keeps pointing at a third-party service that you have stopped using — and someone else claims that service's endpoint. From that moment, an attacker controls content served under your subdomain, with a genuine hostname your users and browsers trust. It is one of the most common and most under-appreciated ways an organisation loses control of a piece of its own domain, and it usually traces back to a single record nobody remembered to delete.
How a dangling CNAME forms
The pattern is mundane. Your marketing team spins up a landing page on a hosted SaaS platform and, to put it on a branded hostname, you add promo.example.com CNAME promo-team.somesaas.io. Months later the campaign ends and someone cancels the SaaS account. The provider deprovisions the endpoint promo-team.somesaas.io, freeing that name for reuse. But nobody removes the CNAME from your DNS. Now promo.example.com still points at a target that no longer belongs to anyone. That is a dangling CNAME — a live alias to a dead destination — and it is the raw material for a takeover.
How an attacker claims it
Attackers scan large numbers of domains looking for exactly this: CNAMEs pointing at services whose target endpoints return a "no such site" or "bucket not found" response, which is the tell-tale sign the backend has been released. When they find one on a platform that lets customers self-select their own subdomain or bucket name, they simply register the same name the deprovisioned resource used. On the SaaS platform, they create an account and claim promo-team.somesaas.io. Now when a browser resolves promo.example.com, DNS still directs it to that endpoint — but the endpoint is under the attacker's control. They serve whatever they like from your hostname.
Why it is so damaging
The danger is that everything about the hostname is legitimate. Visitors see promo.example.com in the address bar. Many platforms will issue a valid TLS certificate for the claimed name automatically, so the padlock appears and there is no certificate warning. The attacker can host convincing phishing pages that harvest credentials, serve malware, or run scams under your brand's authority. Worse, if your main application sets cookies scoped to the parent domain, or trusts its own subdomains for authentication, single sign-on or CORS, the attacker's page can read those cookies or abuse that trust — turning a forgotten marketing subdomain into a foothold against your core systems. Your domain's reputation, built over years, is borrowed in an instant.
Which services are commonly affected
Any platform where customers point a CNAME at a self-chosen, reclaimable endpoint is a candidate. The recurring names are cloud object storage such as Amazon S3 buckets, static-site hosts like GitHub Pages, and a long list of SaaS products — help desks, status pages, form builders, marketing and landing-page tools, CDNs and heroku-style app platforms. The common thread is a two-part setup: a CNAME on your side and a customer-controlled resource name on theirs. When the resource is deleted but the CNAME survives, and the name can be re-registered by anyone, the takeover is possible. Some providers have added domain-verification steps precisely to break this chain, but many have not, and older records predate those protections.
How to find them
Finding dangling CNAMEs is a matter of enumerating your subdomains and checking where each one leads. Start from an authoritative inventory of your DNS zones and list every CNAME record and the target it points at. For each target, ask two questions: does the target still resolve, and does the service behind it still belong to you? A target that resolves but returns a provider's "no such account", "NoSuchBucket", "there isn't a GitHub Pages site here" or similar error page is the classic signature of a takeover-ready record. Combine your internal DNS export with passive subdomain discovery — certificate transparency logs and DNS datasets reveal subdomains you may have forgotten you created. The subdomains most at risk are the ones no team actively owns any more, which is exactly why they slip through. Resolving each alias to the end of its chain, and inspecting what actually answers, is the core check; this site's resolver follows a CNAME chain hop by hop so you can see precisely where an alias terminates.
How to fix and prevent them
The immediate fix is simple: delete the dangling CNAME. If the subdomain is no longer needed, remove the record entirely. If it is still needed, repoint it at a resource you currently control before an attacker gets there. The harder work is prevention, and it is procedural. Make decommissioning a service a two-step action: releasing the resource on the provider and removing the DNS record must happen together, never one without the other. Keep an owner recorded for every subdomain so orphaned records get noticed. Where a provider offers domain ownership verification, use it, so a stranger claiming your endpoint's name cannot serve content on your hostname. And audit your zones regularly rather than once — CNAMEs accumulate quietly, and a record that was safe last year points at a released endpoint today.
Subdomain takeover is fundamentally a DNS hygiene problem, so it belongs to the same discipline as the rest of your zone. Our sibling DNS Studio helps you audit records across a domain, and DNSSEC Studio covers signing your zone so the answers themselves cannot be forged. Neither replaces the basic rule that made all of this avoidable: when a service goes, its DNS record goes with it.