Subdomain Takeover: How a Forgotten DNS Record Hands Over Your Domain

What a subdomain takeover actually is

Start with the mechanics, because the name oversells the drama and undersells the damage. A subdomain takeover happens when a DNS record on your domain still points at a third-party service that no longer claims the name — and someone else claims it instead.

The usual shape is a CNAME. Your status page points at a hosted status provider. Your docs point at a documentation platform. A campaign page points at a site builder. The record is a promise: whatever answers at that provider hostname is me.

Then the account gets cancelled. The provider releases the hostname back into its own pool of available names. Your CNAME does not notice.

It keeps pointing at a name the provider is now willing to hand to whoever asks for it next. That is the entire bug. No payload, no memory corruption, no clever trick — just a pointer that outlived the thing it pointed to.

Here’s the thing that makes a subdomain takeover different from almost every other finding on your external surface: the attacker does not break anything. They sign up for a service, type a hostname into a settings field, and your DNS does the rest of the work for them.

The browser sees a valid hostname on your domain. Many providers will even issue a certificate for it automatically, so the padlock appears too. Everything looks correct, because from the network’s point of view everything is correct. Your domain really did delegate that name.

CNAMEs are the common case, but not the only one. An A record left pointing at an IP address you released back to a cloud provider can be re-acquired by whoever gets that address next. An NS record delegating a zone to a nameserver account you no longer hold is the same failure at a larger scale. The pattern is constant: a reference on your side, a resource that has quietly stopped being yours on the other.

Why dangling records happen in the first place

Honestly, the cause of nearly every subdomain takeover is boring, and that is precisely why this keeps happening. DNS records are created in a hurry and deleted almost never.

Think about the lifecycle of a typical hostname. Marketing needs a page for a launch, so someone adds a CNAME to a landing-page builder in five minutes. The campaign runs. The campaign ends. The subscription lapses. Nobody files a ticket to delete a DNS record, because nobody thinks of the DNS record as part of the campaign.

The same shape repeats across every function in the company:

• Decommissioned marketing sites — the campaign is over, the builder account is closed, the record stays.
• Documentation and support portals — a docs platform gets replaced by a new one, and the old hostname is never cleaned up.
• Status pages — often set up during an incident, forgotten during the calm afterwards.
• Cloud storage buckets — a bucket backing a static site is deleted, but the CNAME to the storage endpoint survives.
• Regional and acquired domains — an acquisition brings in a DNS zone that nobody on the security team has ever looked at.
• Test and staging hosts — spun up on a third-party platform for two weeks and left pointing at nothing for two years.

There is a second, structural reason. DNS is usually managed somewhere far away from the team that owns the resource it points to.

The person who cancels the SaaS subscription and the person who can edit the zone are often different people, in different departments, using different tools. Deleting the resource is a decision. Deleting the record requires someone to remember that the record exists.

Ownership also decays over time. The engineer who created the record leaves. The team is reorganised. The vendor is replaced. What remains is a line in a zone file that no living person can explain, and nobody wants to delete something they cannot explain — so it stays.

That is how a subdomain takeover gets its opportunity. Not through negligence, exactly. Through a gap between two teams that each assumed the other had finished the job.

What an attacker gains from a subdomain takeover

Plenty of teams triage this as low severity and move on. Let’s be real about why that is a mistake: the value of a subdomain takeover is not the content served, it is the identity borrowed.

Phishing from a hostname that is genuinely yours. Every piece of security advice given to employees and customers comes down to “check the domain.” A takeover defeats that advice completely. The page is on your real domain, over HTTPS, with a valid certificate. Email filters, link scanners and trained humans all treat the hostname as trustworthy, because by every mechanical definition it is.

Cookie theft where cookies are scoped to the parent domain. This is the part that turns a defacement into an account compromise. A cookie set with a domain attribute covering the parent domain is sent to every subdomain of it, including one an outsider now controls. If session cookies are scoped that broadly, a hijacked subdomain becomes a collection point.

Bypassing domain-based allowlists. Corporate proxies, content security policies, CORS rules, email gateways and marketing tools all keep lists of trusted domains, and those lists are frequently written as a wildcard over the whole company domain. A subdomain takeover converts every one of those wildcards into an open door.

Abusing OAuth redirect allowlists. OAuth and SSO integrations often permit redirect URLs across a whole domain rather than a fixed list of exact hosts. When that is true, a controlled subdomain becomes a valid redirect target — and authorisation codes or tokens can be steered to it during a login flow.

Brand and trust damage. Even without any of the above, content published under your name is a communications incident. Customers do not distinguish between “our website” and “a hostname on our domain that a third party serves.”

Chain those together and the severity argument writes itself. Trusted hostname, valid certificate, parent-domain cookies, an allowlist that says the domain is fine, and an OAuth configuration that trusts any host under it. The takeover is the first link, not the finding.

That is the case for treating a subdomain takeover as an access-path problem rather than a hygiene ticket. The OWASP Web Security Testing Guide carries a dedicated test for exactly this reason: it is a configuration weakness with authentication-level consequences.

The claim model that makes a subdomain takeover possible

To defend against this you need to understand one design decision that most third-party platforms share, and it is not a flaw in any single vendor.

Hosted platforms let customers bring their own hostname. You point a record at the provider, then tell the provider “this hostname is mine,” and the platform starts serving your content for it. Two separate systems are involved: DNS, which you control, and the provider’s hostname registry, which they control.

A subdomain takeover is what happens when those two systems disagree.

DNS still says the hostname belongs to the provider. The provider’s registry no longer says the hostname belongs to you. Nothing checks that both are still true at the same time, and nothing tells you when one half changes.

Providers handle the mismatch in different ways, and those differences decide whether a dangling record is a genuine subdomain takeover risk or merely untidy:

• Open claim — any account can add any unclaimed hostname. This is the classic exposure, and it is why unclaimed names on these platforms are worth finding before someone else does.
• Verified claim — the provider demands proof of ownership through a separate TXT record or a unique token in the hostname target before serving content. A dangling record is untidy here, but generally not claimable.
• Reserved release — the provider holds a released hostname for a period, or refuses to re-issue it at all.

The practical consequence: a dangling CNAME is a risk indicator, not automatically a vulnerability. Whether it is exploitable depends on the specific provider’s claim model, and that model can change over time. Vendors do tighten this. A record that was safe last year may be claimable after a platform migration, and one that looked claimable may now require verification.

This is also why “is it still resolvable?” is a weak test for subdomain takeover on its own. Some released hostnames still resolve and serve a provider error page. Some claimed-but-empty hostnames return the same error page while remaining firmly attached to an account you own. The response body is a hint, not a verdict.

How to check your own estate for subdomain takeover risk

Before anything else: run this against domains you own or have written permission to test. Everything below is an inventory exercise on your own DNS, not a technique for probing someone else’s.

Step one — get the complete record inventory. Export the zone from every DNS provider your organisation uses. Every provider, not the main one. Acquisitions, regional marketing domains, legacy registrars and that one zone still hosted by an agency all count. A subdomain takeover almost always lives in the zone nobody remembered to include.

Authoritative zone data is the starting point because it is the only source that is complete. Passive enumeration is still worth running alongside it — it catches hostnames in zones you did not know existed, and our guide on how to find subdomains walks through those discovery methods in detail.

Step two — isolate the records that point somewhere you do not control. Filter for CNAME, ALIAS and ANAME records whose target is a third-party provider rather than your own infrastructure. Then do the same for A and AAAA records pointing into cloud IP ranges, and NS records delegating to accounts you may no longer hold.

Step three — resolve the target and see what comes back. If the CNAME target itself returns NXDOMAIN, the name it points to does not exist any more. That is the loudest possible signal, and it deserves attention the same day.

Step four — request the hostname and read the response. Many platforms return a distinctive page when a hostname reaches them without a matching account: some variation of “no such application,” “there is nothing here yet,” or “the specified bucket does not exist.” Those responses are fingerprints. Treat them as evidence worth following, not proof of exploitability.

Step five — confirm claim status with the provider. This is the step people skip, and it is the only one that turns a suspected subdomain takeover into a confirmed one. Log into the provider’s console or query its API and ask a simple question: is this hostname still bound to an account we control?

Three answers are possible, and each has a different response. Still bound to you: the record is fine, note the owner and move on. Not bound to anyone: the record is dangling, and it goes in the remediation queue now. Bound to someone else: you have an active incident, not a finding.

Two cautions about this workflow, both learned the hard way by everyone who has ever run it.

False positives are common. Error pages get reworded, providers change their claim rules, and a fingerprint that was reliable six months ago starts matching healthy hostnames. Any check that only reads response bodies will hand you a queue full of noise.

False negatives are worse and quieter. A hostname that answers with real content today can be released tomorrow when finance cancels a subscription you never knew about. A subdomain takeover check is a snapshot of a state that changes without telling you.

If you want a starting point that requires no setup, our free security checks cover the external-facing basics, including the exposed-hostname problems that sit next to this one.

How to fix a dangling record, in the right order

Fixing a subdomain takeover is not complicated, but the order matters more than the individual steps. Start with the one action that ends the exposure.

Delete the DNS record first. Not later, not after the ownership discussion, not once someone finds the original ticket. Removing the record breaks the delegation immediately, and a hostname that no longer resolves cannot be served by anyone. This works whether the name has already been claimed or not, which is what makes it the right first move in both cases.

People hesitate here because they worry about breaking something. Fair instinct, wrong risk calculation. If the record points at a resource nobody claims, there is nothing left to break — and if deleting it does break something, you have just discovered an owner, which was the goal anyway. Every hour that record survives is another hour a subdomain takeover stays available to whoever looks first.

Then decide what the hostname should be. There are three legitimate outcomes, and only three.

• Leave it deleted. The correct answer for most decommissioned hostnames. A name that serves nothing should not exist in DNS.
• Reclaim it on the provider. If the service is still in use and the binding was simply lost, re-add the hostname in the provider account, confirm it is bound, then recreate the DNS record.
• Repoint it to infrastructure you control. If the hostname is still referenced by customers, documentation or email, point it at your own servers and serve a redirect or a plain notice.

Notice the sequencing in the second option. Bind the hostname at the provider first, create the DNS record second. Doing it the other way around recreates a window where the record exists and the claim does not — the exact condition you are removing.

If the subdomain takeover has already happened, treat it as an incident. Remove the record, capture evidence of what was being served before it disappears, and then work the blast radius rather than the hostname.

That means reviewing what trusted the subdomain. Rotate session secrets if cookies were scoped to the parent domain. Check whether any OAuth or SSO configuration permitted redirects across the domain, and narrow it to exact hosts. Audit CORS rules, content security policies and proxy allowlists for wildcards over your domain. Look at whether internal tools trusted the hostname implicitly.

The takeover itself is usually the least interesting part of the cleanup. What the takeover was trusted by is the real work.

How to prevent subdomain takeover for good

Preventing subdomain takeover comes down to three habits, and none of them requires new tooling or a new budget line.

Give every DNS record an owner. A record with no named owner is a record that will never be deleted. Attach a team, a service name and a review date to every entry — in the record comment, in a spreadsheet, in your infrastructure-as-code repository, anywhere that a human will actually look. Records created through code with a mandatory owner field get this for free.

Put DNS removal in the decommissioning checklist. This single change closes most of the gap. When any service, campaign, bucket or vendor is retired, deleting its DNS records is a required, checked-off step performed by the team doing the retirement.

Pair it with a standing ordering rule that is easy to remember and hard to get wrong:

• Creating: claim the hostname at the provider first, then add the DNS record.
• Removing: delete the DNS record first, then release the resource at the provider.

Follow that order and the dangling window never opens. Reverse it and you create one every time.

Shrink what a hijacked hostname would be worth. Even a perfect process will miss a record eventually, so reduce the payoff of a subdomain takeover in advance. Scope session cookies to the exact host rather than the parent domain wherever the application allows it. List exact hosts in OAuth redirect configurations instead of wildcards. Do the same for CORS, content security policy and proxy allowlists. Avoid wildcard CNAMEs pointing at third-party platforms, since one wildcard can hand over every name beneath it. Keep TTLs short on third-party records so a deletion takes effect in minutes.

The DNS operational guidance in NIST SP 800-81r2 makes the same underlying point about zone data: DNS is production infrastructure with an ownership lifecycle, not a configuration file that only gets appended to.

Then monitor continuously. Diff your zones on a schedule and alert on additions as well as changes. Re-resolve every third-party target and flag anything returning NXDOMAIN. Re-check claim status against provider APIs where they expose it. And review the whole inventory whenever a vendor is replaced or a company is acquired, because those two events create more dangling records than routine operations ever will.

Why a one-time audit goes stale

Here is the uncomfortable arithmetic. Every subdomain takeover starts with a decommissioning, and decommissionings happen constantly — a campaign ends, a vendor is swapped, a bucket is emptied, a subscription lapses in a department that has never spoken to security.

An audit tells you the state of your DNS on the day it ran. The next cancelled subscription invalidates it, and nobody sends a notification when that happens. That is the structural problem: the exposure is created by ordinary business activity, not by an attacker doing something you could detect.

Which means the interesting question is not “do we have a dangling record right now?” It is “how long would one exist before we noticed?”

For most organisations, honestly, the answer is until someone else finds it. That gap is the entire risk, and it is a coverage problem rather than a knowledge problem.

This is the problem SelfHack AI is built around. It maps the external attack surface continuously rather than on a schedule, keeps a live inventory of hostnames and the third-party services they point at, and re-checks when something changes — a new record, a target that stopped resolving, a provider response that shifted.

The subdomain takeover check is one part of a broader external attack surface assessment, and that framing is deliberate. A dangling record rarely arrives alone. It usually appears in the same zone as forgotten staging hosts, expired certificates and admin panels that were never meant to face the internet, because they all come from the same root cause: assets outliving the attention of the people who created them.

If you want to know what your DNS zones are still pointing at, and what would change that answer next month, talk to our team.

The checks that surround subdomain takeover

This one has a hard prerequisite. You cannot spot a dangling record on a host you have never listed, so enumeration comes first.

Start by working out how to find subdomains, then walk the list. For the ones that do resolve to infrastructure you still own, check open ports, run an SSL/TLS check on the HTTPS listeners, and add a security headers check for anything serving a browser.

A subdomain takeover is usually found in the same pass that finds three other things worth fixing. The whole sequence is in our free security checks guide.

FAQ

What is a subdomain takeover in simple terms?

It is what happens when a DNS record on your domain points at a third-party service that no longer recognises the name, and somebody else registers that name on the service. From then on, they choose what your subdomain serves. Nothing is hacked — the delegation you set up is simply still running, aimed at a target that changed hands.

Is a subdomain takeover really high severity?

It depends entirely on what trusts the subdomain, which is why blanket severity ratings are unhelpful. On its own, a hijacked hostname serving arbitrary content is a phishing and brand problem. Combined with parent-domain cookies, a wildcard OAuth redirect rule or a domain-wide allowlist, the same finding becomes a route to account compromise. Score it by the trust it inherits.

How do I know whether a dangling CNAME can actually be claimed?

Ask the provider, not the response body. Error pages are useful hints but unreliable proof, and claim rules differ between platforms and change over time. The reliable check is administrative: log into the provider account or query its API and confirm whether the hostname is still bound to you. If it is bound to nobody, the record is dangling and should be removed.

Can I test for subdomain takeover on domains I do not own?

No. Registering a hostname on a service so that it serves content for someone else’s domain means taking control of infrastructure that is not yours, whatever the intention behind it. Restrict this work to domains your organisation owns or has explicit written authorisation to test. If you find a dangling record belonging to another organisation, report it through their disclosure channel and stop there.

Does deleting the DNS record fix a takeover that already happened?

It ends the exposure, which is the urgent part — a hostname that no longer resolves cannot be served by anyone. It does not finish the job. Anything that trusted the subdomain still needs review: session cookies scoped to the parent domain, OAuth redirect configurations, CORS rules and any allowlist covering your domain with a wildcard.

Which subdomains get forgotten most often?

The ones created outside engineering and retired without a ticket. Campaign and landing pages, documentation portals, status pages, storage buckets behind static sites, and anything inherited through an acquisition. The common thread is that a non-technical team started the service and a technical team owns the DNS, so nobody owns the ending.

The verdict: your DNS zone is an asset register

Most security work is about defending things you know you have. A subdomain takeover is the opposite problem. It is an attack on the things you forgot you had, made possible by a record that is still faithfully doing the job it was given years after the job stopped existing.

The truth is that a DNS zone is an asset register that nobody treats like one. It is append-only in practice, edited by several teams, rarely reviewed line by line, and trusted implicitly by browsers, mail filters, proxies and authentication systems alike. That combination is what turns a forgotten record into a usable identity.

So the fix is not clever. Know every record you have published. Know what each one points at, and whether that thing still belongs to you. Delete the record the moment the resource goes away, and check again after the next change, because there is always a next change.

Do that consistently and a subdomain takeover stops being a thing that happens to you. It becomes a thing you cleaned up on a Tuesday, before anyone else went looking for it. If you would rather find out from us than from a customer, let’s map what your DNS is still pointing at.

Sources & further reading: the OWASP Web Security Testing Guide includes a dedicated subdomain takeover test under configuration and deployment management. DNS operational and ownership guidance: NIST SP 800-81r2, Secure DNS Deployment Guide. Adversary use of acquired and compromised domain infrastructure is catalogued in MITRE ATT&CK T1584. This article describes attack mechanics at a conceptual level for defensive purposes; test only domains you own or are authorised to test.