Subdomain Takeover: How It Works and How to Check Your Domains
A forgotten DNS record can hand an attacker your subdomain — and your brand. Here is how subdomain takeover works, why it happens, and how to audit your domains for it.
Subdomain takeover is one of the quietest high-impact vulnerabilities in web security. Nothing on your main website is broken. No code was flawed. Yet an attacker can serve content on shop.yourdomain.com — complete with a valid TLS certificate for your domain — because a DNS record points at a service you stopped paying for months ago. In this guide we explain exactly how takeover happens, which patterns to look for, and how to audit your entire domain footprint systematically.
How Subdomain Takeover Works
The attack exploits the gap between DNS and cloud resources:
- Your team once pointed
campaign.example.com(a CNAME) at a third-party service — a Shopify store, a Heroku app, an Azure cloud endpoint, a GitHub Pages site. - The project ended, the subscription lapsed, or the workspace was deleted. The service no longer claims that name.
- The DNS record stays. DNS records do not disappear when the service behind them is deleted.
- An attacker registers a new resource on that same service using the same name. Now the DNS record — your record — resolves to their content.
Because the hostname is your subdomain, browsers show your domain in the address bar. Because the attacker provisions the resource legitimately, TLS certificates are issued for it. From a visitor's perspective, it is your site. That enables credential phishing against your customers, malware distribution under your brand, cookie theft against sibling subdomains, and damage to the domain reputation you spent years building.
Where Takeovers Hide
Takeovers are not limited to one provider. The recurring pattern is any dangling CNAME, A, or AAAA record whose target resource can be re-registered by someone else. Common historical sources include:
- E-commerce and landing-page SaaS (shops, helpdesks, marketing pages)
- PaaS application hosts (abandoned apps, deleted projects)
- Static-site hosts and CDN endpoints with unclaimed custom domains
- Object storage buckets with custom-domain bindings
- Ticketing, documentation, and status-page products
The fingerprinting part is the hard bit: for each subdomain, a scanner must resolve the record, follow the CNAME chain, probe the target service, and recognize that service's "this resource does not exist" page — because that exact response is what signals availability for takeover.
Why "Just Delete Old Records" Isn't Enough
Most organizations cannot answer a simple question: what subdomains do we actually have? Between marketing campaigns, departed developers, acquired companies, and forgotten test environments, the DNS zone is usually much larger than anyone's mental model. Subdomain inventories rot quickly because:
- Different teams create records in different zones and registrars
- Third parties create DNS records for verification purposes and never clean them up
- Certificate transparency logs reveal subdomains the security team never knew existed
- Wildcard certificates keep old names resolving long after their purpose is gone
A takeover check therefore has to start from discovery, not from the zone file you already know about.
How a Takeover Audit Actually Works
Our engine treats subdomain takeover as a pipeline, not a single check:
- Multi-source subdomain enumeration — the Subdomain Enumeration (Multi-Source) and Advanced Subdomain Discovery scanners pull candidate names from passive DNS, certificate transparency (including sibling discovery through live certificates and crt.sh), search-engine dorking, historical URL mining (gau, waymore), and Amass passive sources — nine sources in total, cross-validated.
- Resolution and liveness — every candidate is resolved and probed (
httpx); NXDOMAIN-on-CNAME and unclaimed-service responses are the signals we hunt for. - Dangling-record detection — the Subdomain Takeover (Dangling CNAME) scanner fingerprints responses against known "resource not claimed / available for registration" signatures across providers, and only then reports.
- Context intel — supporting scanners check DNS zone transfer (AXFR) misconfigurations, DNSSEC validation, SPF/DMARC posture for the parent domain, and whether Cloudflare is hiding an origin IP that itself may expose stale services.
Each finding includes the subdomain, the dangling record, the target service, and the takeover fingerprint — so your team can verify and fix in minutes: delete the record, or re-claim the resource.
Fixing and Preventing Takeovers
- Delete dangling records the moment a third-party service is cancelled — make it part of the offboarding checklist for every SaaS.
- Own the zone — consolidate DNS where possible, and monitor zone changes.
- Continuously re-check — new dangles appear every quarter; a one-time audit decays within months.
- Monitor certificate transparency for your domain — certificates issued for unknown subdomains are a leading indicator of takeover activity.
Check Your Domain Footprint
The free 2MNY security scan covers the fundamentals, and deep scans run the full subdomain and takeover pipeline described above across your entire footprint. You can see every scanner involved — from Certificate SAN Sibling Discovery to Passive-DNS History Analysis — on the features page, and the same engine core is available for self-hosting on GitHub.
Related reading: Why Continuous Security Monitoring Matters · Configure SPF, DMARC and DKIM · Cloud Misconfiguration Scanning
1 What is subdomain takeover?
Subdomain takeover happens when a DNS record (usually a CNAME) points to a service that no longer exists — a deleted GitHub Pages site, a torn-down cloud resource, an expired SaaS trial. If the service allows re-registration, an attacker claims it and inherits your subdomain: your HTTPS certificate, your domain's reputation, and your users' trust.
2 How do I check if my subdomains can be taken over?
Enumerate every DNS record across your domain, resolve each target, and fingerprint whether the destination returns a "resource not found but claimable" signature from a known-vulnerable service. 2MNY automates the whole chain — multi-engine subdomain enumeration, dangling-record detection, and service fingerprinting — as part of its attack-surface scans.
3 Which services are vulnerable to takeover?
Historically the list includes GitHub Pages, Heroku, AWS S3/CloudFront, Azure sites, Shopify, Fastly, Pantheon, and dozens more — each with a distinctive error-page fingerprint when the underlying resource is gone. The list changes as services change their claim policies, which is why fingerprint databases need constant updates.
4 How do I prevent subdomain takeover?
Delete DNS records the moment you decommission the service they pointed to, treat DNS as code with an inventory, and monitor continuously so a dangling record is caught in hours, not years. The 2MNY scanner flags takeover candidates automatically during attack-surface monitoring.
