Subdomain Takeover: What It Is and How to Fix It

You set up a subdomain months ago pointing to a landing page builder, a documentation host, or a staging environment. The project ended, so you deleted the account on that service. The DNS record pointing to it, though, is still sitting there — and now anyone who signs up for that same service can claim your old subdomain name and serve whatever content they want under your domain.

How Does a Subdomain Takeover Actually Work?

Most third-party platforms work by having you point a CNAME record from your subdomain to a domain they control. As long as your account on that platform is active, this is completely normal. The moment you delete the account or project, though, that target domain becomes unclaimed — and most platforms let anyone register a new project with the same name. Your DNS record is still faithfully pointing there, so whoever claims it next effectively controls what loads on your subdomain.

This is called a dangling DNS record, and it's a well-documented category of vulnerability precisely because it's so easy to create by accident and so easy to overlook during cleanup.

What Does an Actual Takeover Attempt Look Like?

In practice it's rarely dramatic. An attacker running automated scanners looks for exactly the dangling-CNAME pattern described above across huge lists of domains, not specifically yours — you're caught by the scan, not individually targeted. Once they find an unclaimed target, they sign up for a free account on the same platform, claim the matching project name, and within minutes your subdomain serves their content instead of an error page. From there it's commonly used for phishing (a fake login page under a trusted-looking subdomain), malware distribution, or simply defacement. The entire process, from discovery to a live malicious page, can take under an hour once a dangling record is found — which is why periodic auditing matters more than reacting after the fact.

How Do You Check If You're Vulnerable?

1. List every subdomain your domain has — check your DNS panel directly rather than relying on memory, since old marketing or dev subdomains are the most commonly forgotten.
2. Look at each subdomain's [DNS record type](/blog/dns-record-types-explained) — CNAME records pointing to external platforms are the ones to scrutinize.
3. Check whether the service each CNAME points to is still active under your account. If you can't find it in any of your current service dashboards, that's a signal.
4. Try loading the subdomain directly. An error page specific to the third-party platform, rather than your own site's error page, claiming the name isn't configured or doesn't exist is a strong indicator the target is unclaimed and takeover-ready.
5. Use a subdomain enumeration tool if you manage a larger domain portfolio, to catch subdomains that aren't in active use anywhere but still resolve.

How Do You Fix and Prevent It?

Remove the DNS record entirely for any subdomain tied to a service you no longer use — don't just leave it in case. If you might need the subdomain again later, it costs nothing to recreate the record when you actually do.

Build a decommissioning step into your process: whenever a team member cancels a third-party service, checking for and removing the associated DNS record should be part of that same task, not a separate cleanup pass weeks later. This matters even more across a larger domain portfolio or an agency managing DNS for multiple clients, where records accumulate across different people and projects over time.

If security compliance matters for your business, DNSSEC doesn't directly prevent subdomain takeovers, but a general discipline of auditing and signing your DNS zone tends to catch these dangling records as a side effect of the review process. The core fix, though, is simple and doesn't need special tooling: delete what you don't use.

Quick Answers

Never lose a domain again

Track every domain you own in one dashboard. Free for up to 15 domains.