You launch a marketing site on a cloud host, point promo.yoursite.com at it, run the campaign, and later shut the host down. Job done — except the DNS record still quietly points at an address nobody owns anymore. Months later, someone else claims that address and now controls a page on your domain. That is a subdomain takeover, and it is one of the most overlooked risks on the modern web.
Also see: DNS Security Best Practices, Third-Party Script Security, and Website Security Checklist 2026.
What Is a Subdomain Takeover? (In Plain Language)
Think of a DNS CNAME record as a forwarding address: "mail sent to shop.yoursite.com should really go to myshop.some-cloud.com." That works perfectly while you rent myshop.some-cloud.com.
But when you stop renting it and forget to remove the forwarding address, your subdomain now points to an empty lot. Cloud providers hand out these addresses on a first-come basis — so anyone can walk up, rent that exact address, and put up their own building. Visitors typing your trusted subdomain land on the attacker's content, with your domain in the address bar.
Why It's So Dangerous
The danger isn't the empty subdomain — it's the trust your domain carries. Once an attacker controls content on your subdomain, they can:
- Run believable phishing — a login page on
account.yoursite.comlooks completely legitimate to your users and to email filters. - Steal cookies scoped to your domain, potentially hijacking sessions on your main site.
- Bypass trust rules — some CORS allow-lists and CSP policies trust "any subdomain of yoursite.com," which now includes the attacker.
- Damage brand & email reputation — malware served from your domain can get your whole domain blocklisted.
Because the content lives on your real domain, users, search engines, and security tools all treat it as genuinely yours. That inherited trust is exactly what makes takeover attractive.
How to Find Dangling Records
Step 1 — list your subdomains and where they point. Export your DNS zone from your provider (Cloudflare, Route 53, GoDaddy…), or check from the command line:
# See what a subdomain points to
dig CNAME promo.yoursite.com +short
nslookup promo.yoursite.com
# Then open the subdomain in a browser and watch for tell-tale errors:
# "There isn't a GitHub Pages site here"
# "NoSuchBucket" (AWS S3)
# "No such app" (Heroku)
# "404 Not Found - Fastly / Netlify"
# Any of these on a live subdomain = likely dangling / takeover-able.Step 2 — the tell: a subdomain is at risk when its DNS record still resolves to a cloud provider, but that provider replies with a "not claimed / not found" message. That gap between "DNS points here" and "nobody owns this" is the vulnerability.
Our free scanner checks discovered subdomains for these fingerprints automatically and flags "Potential subdomain takeover" when it sees one.
How to Fix It
There are only two correct fixes — pick based on whether you still need the subdomain:
Option A — You no longer use it: delete the DNS record
# The permanent fix: remove the dangling record entirely.
# Example (AWS Route 53 CLI) — delete the stale CNAME:
aws route53 change-resource-record-sets \
--hosted-zone-id ZXXXXXXXXXXXXX \
--change-batch '{"Changes":[{"Action":"DELETE","ResourceRecordSet":{
"Name":"promo.yoursite.com","Type":"CNAME","TTL":300,
"ResourceRecords":[{"Value":"myshop.some-cloud.com"}]}}]}'
# In most dashboards (Cloudflare, GoDaddy): DNS → find the record → Delete.Option B — You still need it: reclaim the target
Re-create the resource on the cloud provider so you own the address the CNAME points to again (re-create the S3 bucket, GitHub Pages site, Heroku app, etc.). Then confirm it serves your content — not a "not found" page.
When decommissioning any cloud service, remove the DNS record first, then delete the cloud resource. Doing it the other way around leaves a dangling record — even if only for a few minutes, automated bots scan for exactly this window.
How to Prevent It Forever
- Add a decommission checklist: every time you retire a service, the DNS record removal is step one.
- Audit DNS quarterly: export your zone and confirm every CNAME still points somewhere you control.
- Add CAA records so attackers can't easily issue TLS certificates for a subdomain they grab — see our DNS Security Best Practices.
- Re-scan regularly: new subdomains and retired services appear constantly — a periodic scan catches the next dangling record early.
Check Your Subdomains for Takeover Risk
Free scan — enumerates your subdomains and flags dangling records pointing to unclaimed cloud services in 60 seconds.
Scan Your Site NowFrequently Asked Questions
What is a subdomain takeover?
It happens when a subdomain still points via DNS to a cloud service you no longer use. Because the service is unclaimed, an attacker can register it and serve their own content from your trusted subdomain.
How dangerous is a subdomain takeover?
Very — the malicious content sits on your real domain, so attackers can run convincing phishing, steal domain-scoped cookies, bypass some CORS/CSP trust rules, and harm your brand and email reputation.
How do I fix a dangling CNAME record?
Delete the DNS record if the subdomain is no longer needed, or re-create the cloud resource it points to so you own it again. When decommissioning a service, always remove the DNS record first.