How to prevent subdomain takeover

Published September 25, 2026 · about a 6-minute read

Somewhere in your DNS there's probably a subdomain you forgot about — status., blog., promo-2023. — still pointing at a service you shut down ages ago. It looks harmless. It isn't. That leftover record is a door left unlocked, and the person who walks through it gets to publish whatever they want on your domain.

This is subdomain takeover, and it's one of those attacks that's embarrassingly easy to pull off and almost as easy to prevent, once you know where to look.

How it works

Say you once hosted help.yoursite.com on a third-party service and set a CNAME pointing there. Later you cancelled the service but left the CNAME in place. Now that hostname points at nothing you control — a "dangling" record.

An attacker finds it, goes to that same service, and provisions a new resource claiming your hostname. Most of these platforms let anyone map a custom domain without proving they own it, so the attacker doesn't need to touch your DNS at all. They just claim the target you left pointing at empty space. Minutes later, help.yoursite.com serves their content.

The usual suspects are services that let users claim custom hostnames on shared infrastructure — AWS S3, CloudFront, Azure blob storage and Traffic Manager, Heroku, GitHub Pages, and similar. Each leaves a tell-tale error while the record is dangling: S3 says NoSuchBucket, Heroku says "No such app," and so on. Those error pages are exactly what attackers scan for.

Why it's worse than "an old page got defaced"

The damage isn't the subdomain itself — it's that the content now lives on your domain, wearing your name and a valid padlock. That trust is the whole prize:

• Believable phishing. A login form on a real subdomain of your company fools people your main site never could.
• Cookie theft. If you set cookies scoped to the parent domain, a taken-over subdomain may be able to read them.
• Trust bypass. CORS allowlists, CSP connect-src entries, and OAuth redirect rules that trust "our own subdomains" now trust the attacker.
• Reputation. Malware or spam served from your domain drags down your brand and your email deliverability with it.

A subdomain takeover isn't someone breaking into your house. It's someone moving into the guest cottage you forgot you owned — and putting your name on the mailbox.

Find your dangling records before someone else does

You can't fix what you can't see, and most orgs have no current inventory of their own subdomains. Build one:

1. Enumerate every subdomain. Pull them from your DNS zone, and — critically — from certificate transparency logs (every TLS cert ever issued for your domain is public), which surface subdomains you've long forgotten. Add active scanning if you have a lot.
2. Resolve the CNAME chains. For each subdomain, follow where it points. Flag anything aimed at a third-party service.
3. Check each external target. Does the service still host something for you, or does it return a "not found" signature (NoSuchBucket, "No such app," a default placeholder page)? Those are your live vulnerabilities.
4. Do it on a schedule. A one-time audit ages out the next time a team spins something down. Weekly is a reasonable floor.

The fix is mostly about order of operations

Here's the mistake behind almost every takeover: teams decommission in the wrong order. They delete the cloud resource first and get to the DNS record "later" — and that gap between the two is the entire vulnerability window. Flip it:

• Remove the DNS record the moment you tear down what it points to — ideally before. No dangling window, no takeover.
• If the subdomain still needs to exist, repoint it at a resource you currently own and control, not the old target.
• Manage DNS in version control (Terraform, OctoDNS, DNSControl) so every add and remove is reviewed and logged — this is how "someone deleted the app but not the record" stops happening.
• Sweep periodically for records pointing at resources that no longer exist in your accounts.

Why this needs watching, not a one-off cleanup

Dangling records aren't created by attackers — they're created by your own team, every time someone sunsets a marketing site, a status page, or a trial integration and forgets the DNS. You can clean up today and have a fresh one by next sprint. It's the same pattern behind a lapsed certificate or a DNS misconfiguration: silent until it's exploited. Something should be watching your domains continuously and flagging a subdomain the day it starts pointing at nothing.

See your current DNS posture with our free site checker — it grades your DNS, TLS and headers in seconds, no signup. For agencies and teams juggling lots of subdomains, continuous monitoring is what turns "we'll audit it someday" into "we knew within a day."