Subdomain takeover happens when a DNS record for one of your subdomains still points to a cloud resource that's been deleted or deprovisioned, and an attacker claims that resource before anyone notices the record is dangling. You detect subdomain takeover vulnerabilities by inventorying every CNAME and A record across every DNS zone you control and checking whether the destination still belongs to you — a one-time scan misses records that go dangling the day after you run it.
- Subdomain takeover starts with a dangling CNAME record pointing at a deprovisioned cloud resource — S3, Heroku, Azure, and GitHub Pages are common targets.
- Detect subdomain takeover vulnerabilities by auditing every DNS record against live service ownership, not by running a one-time port scan.
- Once an attacker claims the resource, they can obtain a free, domain-validated TLS certificate in minutes and host content under your trusted domain.
- Remediation means deleting the orphaned record or reclaiming the resource, then re-scanning continuously since new dangling records appear constantly.
- Secfolio’s external exposure management maps dangling DNS records as part of continuous attack surface discovery, closing the gap before attackers find it.
Why this matters
A dangling DNS record doesn't show up in a vulnerability scanner the way an open port does. The record resolves, the domain looks legitimate, and browsers trust the free, domain-validated TLS certificate an attacker can obtain in minutes and keep valid for up to 90 days. That combination — your domain, a valid certificate, and content the attacker controls — is what makes subdomain takeover useful for phishing pages, cookie theft, and malware distribution in 2026, not a theoretical DNS misconfiguration.
Security teams that treat exposure management as a point-in-time audit miss this class of finding entirely, because subdomains go dangling continuously: a marketing team spins down a campaign microsite, a dev team retires a staging environment, an integration with a SaaS vendor gets deprovisioned — and the DNS record nobody remembered to delete stays live. Detecting external exposure before attackers do has to include DNS record hygiene, not just open ports and expired certificates.
How do you detect subdomain takeover vulnerabilities?
- Inventory every DNS record you own. Pull every CNAME, A, NS, and MX record across every zone and subdomain — including ones registered years ago and forgotten.
- Resolve each CNAME target and check ownership. A CNAME pointing to a Heroku app name or an S3 bucket name only stays safe if you still control that resource.
- Flag known-vulnerable service patterns. Cloud platforms that let any customer claim a previously used subdomain — S3 buckets, GitHub Pages, Heroku, Azure services, and CDN configurations like Fastly — are the most common source of exploitable dangling records.
- Verify, don't guess. For flagged records, confirm the underlying resource is genuinely unclaimed rather than assuming from the DNS response alone; false positives waste remediation time.
- Prioritize by exposure, not alphabetically. A dangling record on a subdomain linked from your homepage, SSO login flow, or API documentation carries more risk than one buried in an unused staging path — prioritizing external exposure findings for remediation keeps the team fixing what attackers would find first.
- Re-scan continuously. New dangling records appear every time a team decommissions a service, and since DNS changes can take up to 48 hours to fully propagate, treat any freshly deleted record as still discoverable until that window closes.
Where dangling DNS records show up most often
Cloud storage and static hosting
S3 buckets, Azure Blob Storage, and GitHub Pages are reused by design — anyone can register a bucket or repo name that a previous customer released, which is exactly what makes a CNAME pointing at a deleted one exploitable.
PaaS platforms
Heroku, Netlify, and similar platforms map subdomains to app names; once an app is deleted, the name becomes available again, and the old DNS record still points at it.
CDN and edge services
Fastly and comparable CDN services assign domains to customer configurations; a decommissioned configuration frees the mapping for anyone else to claim while your CNAME still points there.
None of this shows up unless reducing external attack surface across cloud assets includes DNS-level checks alongside the usual port and certificate scanning.
Why subdomain takeover risk varies across organizations
- Decommissioning workflow maturity — teams that treat DNS cleanup as a required step in service retirement carry far less dangling-record risk than teams that only tear down the compute resource.
- Number of DNS zones and subdomains in use — organizations running dozens of marketing microsites, regional domains, or M&A-inherited zones accumulate more forgotten records.
- Third-party SaaS sprawl — every vendor integration that points a subdomain at a hosted service is a future dangling record the day that vendor relationship ends.
- Ownership fragmentation — when marketing, dev, and IT each provision subdomains independently, no single team has visibility into the full DNS inventory.
- Scan frequency — a single annual audit misses records that go dangling the week after the audit runs.
- Record hygiene practices — long-lived, undocumented CNAME records outlive the projects they were created for.
“A dangling CNAME record is an open invitation: the resource is gone, but the trust in your domain is not.”
Common questions about subdomain takeover
Is subdomain takeover the same as DNS hijacking?
No — subdomain takeover exploits a dangling record you still control the authority for, while DNS hijacking compromises the DNS provider or registrar account itself. Subdomain takeover doesn't require any credential compromise; it only requires a resource an attacker can claim.
Can subdomain takeover lead to phishing or credential theft?
Yes — a claimed subdomain inherits your domain's trust, so attackers use it to host phishing pages or credential-harvesting forms that look legitimate to both users and email filters. Pairing exposure management with passwordless authentication removes the payoff even when a phishing page succeeds, since there's no reusable password left to harvest.
How often should you scan for subdomain takeover?
Continuously, not periodically — dangling records appear the moment a service is decommissioned, so exposure discovery needs to run on an ongoing basis rather than a quarterly or annual cycle in 2026.
Close external exposure gaps now
Map dangling DNS records before attackers claim them.
FAQ
What is subdomain takeover?
Subdomain takeover is a vulnerability where a DNS record for your subdomain still points to a cloud resource that’s been deleted or deprovisioned, letting an attacker claim that resource and serve content under your trusted domain. It doesn’t require breaking into your DNS provider — it only requires finding a record you forgot to remove.
How do you detect subdomain takeover vulnerabilities?
You detect subdomain takeover vulnerabilities by inventorying every CNAME, A, and NS record across every DNS zone you own, then checking whether each destination resource still belongs to you. Continuous discovery in 2026 catches records that go dangling between scans, which periodic audits miss.
What causes a DNS record to go dangling?
A DNS record goes dangling when the cloud resource it points to — an S3 bucket, a Heroku app, a GitHub Pages site — gets deleted or renamed, but nobody removes the DNS record pointing at it. Service decommissioning workflows that skip DNS cleanup are the most common cause.
Which cloud services are most vulnerable to subdomain takeover?
Cloud storage and PaaS platforms that let any customer claim a previously used name — S3 buckets, GitHub Pages, Heroku, Azure services, and CDN configurations like Fastly — are the most common subdomain takeover targets. Any service where names get reused after deletion carries the same risk pattern.
Can automated scanners catch subdomain takeover?
Automated scanners catch some subdomain takeover candidates by pattern-matching CNAME targets against known vulnerable service signatures, but they miss records pointing at custom infrastructure. Manual verification is still required to confirm a flagged record is genuinely exploitable, not a false positive.
How do you remediate a subdomain takeover vulnerability?
You remediate a subdomain takeover vulnerability by removing the dangling DNS record immediately or reclaiming the underlying resource so an attacker can no longer register it. The record itself is the vulnerability — deleting it closes the gap even before you investigate how it went dangling.
Does subdomain takeover affect SEO or email deliverability?
Yes — a subdomain claimed by an attacker can get flagged by search engines and email security filters, which drags down the reputation of the parent domain alongside the direct security risk. Cleaning up dangling records protects domain reputation as much as it prevents phishing abuse.
Is subdomain takeover covered by standard penetration tests?
Standard penetration tests cover subdomain takeover only when the scope explicitly includes full DNS zone review, since most engagements focus on live, in-scope applications rather than every historical subdomain. Continuous external exposure management catches what a point-in-time pentest window misses.
One last thing
Subdomain takeover rarely comes from a sophisticated attack — it comes from a decommissioning checklist that never included "delete the DNS record" as a step. Mature security programs get bitten by this in 2026 as often as newer ones, because the gap isn't a skill problem, it's a process gap between whoever deletes the cloud resource and whoever owns the DNS zone. Fixing the record takes minutes; finding it before an attacker does is the actual work.
Related guides
- Close external exposure gaps before an audit
- Detect exposed secrets and API keys in code repositories
