Subdomain takeover happens when a DNS record for your subdomain still points to an external service that's been deprovisioned or never claimed — a dangling record. An attacker claims that service and serves their own content on your subdomain, inheriting your domain's trust: phishing under your brand, cookie theft, OAuth/redirect abuse, reputation and SEO damage. Detect it by enumerating all subdomains and checking for records pointing to unclaimed services. Prevent it by removing DNS records the moment you decommission the service — the dangling record is the root cause. It's a standard check in web and network tests and attack-surface monitoring.
// 01 What subdomain takeover is
Your DNS is full of records that point subdomains at external services — blog.example.com to a cloud host, docs.example.com to a SaaS documentation platform, status.example.com to a status-page provider. Each is usually a CNAME pointing at the provider's hostname. The problem arises when you stop using that service but forget to remove the DNS record. Now the subdomain points at a target that no longer belongs to you and is available for anyone to claim. An attacker who registers that same service name suddenly serves their content on your subdomain. That leftover pointer is the "dangling" record, and it's the entire vulnerability.
// 02 Why it's dangerous
The danger comes from a single fact: the malicious content is served from your own domain, so it inherits all the trust your domain carries. That opens several attacks:
- Convincing phishing hosted under your real brand — users see a legitimate subdomain and trust it.
- Cookie theft and session abuse where cookies are scoped to the parent domain and shared with subdomains.
- Bypassing controls that trust your domain — OAuth redirect URIs, CORS allow-lists, cookie scopes.
- Reputation, malware and SEO damage from attacker content living on your namespace.
Because it exploits configuration (a stale DNS record), not a software bug, there's no patch — and it's easy to miss precisely because the affected subdomains are the forgotten ones.
// 03 How to detect the risk
Detection is a two-step exercise, and the first step is the one people skip:
Enumerate every subdomain
Comprehensively — DNS records, certificate transparency logs, and OSINT. Forgotten subdomains are exactly the ones at risk.
Inspect the targets
For each CNAME/ALIAS to an external service, check whether the target still exists and is claimed by you. An "unclaimed" or "not found" response is the red flag.
This is a routine check in a network and web application test — and the reason comprehensive discovery matters is that the vulnerable subdomains are, by definition, the ones nobody remembers.
// 04 How to prevent it
The fix is refreshingly simple because there's a single root cause: remove the DNS record the moment you decommission the service it points to. No dangling record, no takeover. To make that reliable rather than aspirational:
- Maintain a subdomain inventory mapping each record to its target service and owner.
- Bake DNS cleanup into decommissioning — retiring a service isn't done until its DNS is removed.
- Review DNS regularly for stale entries pointing at unused providers.
- Monitor continuously — attack-surface management catches new dangling records as they appear.
Validate all of this with periodic testing, which will surface any dangling records before an attacker does.
// 05 Frequently asked questions
What is a subdomain takeover?
When a DNS record for your subdomain still points to an external service that's been deprovisioned or never claimed — a dangling record. An attacker claims that service and serves their own content on your subdomain, inheriting your domain's trust.
Why is it dangerous?
The attacker's content is served from your own domain, inheriting its trust — enabling convincing phishing under your brand, cookie theft, OAuth/CORS abuse, and reputation, malware or SEO damage. Impact ranges from reputational harm to credential theft.
How do you detect the risk?
Enumerate all subdomains comprehensively, then inspect records pointing to external services and check whether each target still exists and is claimed by you. A dangling record — pointing to an unclaimed service — indicates a takeover risk. Pentests and attack-surface tools include this check.
How do you prevent it?
Remove DNS records as soon as you decommission the service they point to — the dangling record is the root cause. Maintain a subdomain inventory, review DNS regularly, bake cleanup into decommissioning, and monitor continuously for new dangling records.
// 06 References
- OWASP — attack references and DNS/subdomain security guidance.
- Related: our network penetration testing and technical deep-dives.