DNS
Subdomain takeover checker
Follow a subdomain's CNAME to its target and say whether that target looks abandoned enough for someone else to claim.
Free, no accountLive check
Result
The verdict appears here once you press Check for a takeover.
What this is
This subdomain takeover checker follows a name's CNAME to its target and asks the one question that actually matters: does that target still belong to anyone, or has it been left abandoned for someone else to claim and serve content from in your name?
A subdomain takeover happens when a CNAME keeps pointing at a third-party service - a static host, a PaaS app, a storage bucket - after whatever used to live there is gone. The alias is still published and still resolves through DNS exactly as configured; what changed is that the name on the other end is now free, so anyone who registers or claims it on that service starts serving content under your domain instead.
Some providers make an abandoned target obvious by letting the target name itself stop resolving at all, which this checker reads the same way it reads any missing DNS name. Others keep answering, because the provider's own infrastructure still exists - only the specific project or app name was released - so the only tell is the exact wording of the "nothing here" page that name now serves, which is what the fingerprint list in this tool exists to recognise.
How to read the result
Two unrelated findings both mean a takeover is possible, and this page keeps them apart rather than folding them into one badge: the target itself may no longer exist at all, or it may exist and simply match a provider pattern this tool keeps a fingerprint for - in which case the subdomain's own page is fetched once and checked against that provider's known unclaimed wording before anything is called a confirmed match.
A target that matches a provider pattern but is clearly still in use gets its own distinct result rather than a scary one: the page served there right now does not read like that provider's unclaimed page, so this is reported as in use, not flagged as a vulnerability waiting to happen.
Common mistakes
What goes wrong most often, and how to tell.
- Assuming a CNAME that still resolves means the target is still yoursDNS resolving successfully only means the provider's own servers answered - it says nothing about whether the specific app, bucket or project name behind that CNAME still belongs to anyone at your organisation.
- Deleting a cloud resource without removing the CNAME that pointed at itDecommissioning a hosted app or bucket releases its name back to the provider for anyone to claim, but the DNS record pointing your subdomain at that name is a separate thing that has to be removed on its own.
- Treating every CNAME to a well-known provider as inherently riskyA CNAME pointing at GitHub Pages, Heroku or any other platform in daily use is completely normal - the risk is specifically an abandoned one, not the provider itself, which is why this checker fetches the live page before calling anything a match.
Questions
What people ask about this tool.
- A CNAME record that still points at a third-party service after the specific resource behind it - an app, a bucket, a project - has been deleted or let expire, so its name on that service is free again for anyone else to claim and start serving content from.
- Some providers keep their own infrastructure answering normal DNS queries long after a specific app or project name has been released, so the target never shows up as missing in DNS at all - the only reliable sign is the exact wording of the "not found" page that name now serves, which this tool checks against a maintained fingerprint for each provider.
- No. Matching a provider's domain pattern only means the target is worth checking - the page fetched from the subdomain itself still has to read like that provider's unclaimed page before this tool calls it a match, and a target that is clearly still serving real content is reported as in use instead.
- Claim the exact target name on that provider yourself before anyone else can, which immediately closes the gap, or simply remove the dangling CNAME from your own DNS if the service behind it is no longer needed at all.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.