Subdomain Takeover Checker
Find dangling CNAMEs an attacker could claim. Follows the CNAME chain, matches 39 hosting services, and confirms with the service’s unclaimed-page fingerprint.
How to check for subdomain takeover
- Paste up to 15 hostnames, separated by commas, spaces or new lines, for example
blog.example.comandstatus.example.com. Subdomains that use a CNAME to a hosted service are the ones worth checking. - Press Check. For each host, this server follows the CNAME chain (up to 8 hops), matches each target against the fingerprint database, tests whether the last target still resolves and, for a known service, fetches the page to look for that service's "unclaimed" message.
- Sort out anything marked high first, then export the table as CSV or JSON for your ticket or report.
What the result means
- Vulnerable (high): the service returned its unclaimed-resource page, or the CNAME target no longer resolves, and the service is listed as allowing takeover. For example,
docs.example.com CNAME example-docs.github.ioshowing GitHub's “There isn't a GitHub Pages site here” page. Verify by hand, then remove the record or reclaim the resource. - Edge case (medium): the same signal on a service where a takeover works only under some conditions, such as GitHub Pages, Heroku or Netlify. Treat it as real until you have checked.
- Not claimable (low): the record is stale, but the service checks domain ownership, so another account cannot claim the name. Remove the record anyway.
- Dangling (medium): the CNAME target does not resolve and is not a known service. If the target’s domain has expired, anyone who registers it controls this name; check its registration with Domain Availability.
- In use: the CNAME points to a live resource on a known service. Confirm the account belongs to you.
- Unknown target: the target resolves but is not in the database. Check manually whether it still serves your content.
- DNS error: the resolver did not answer for the CNAME target. A timeout is not proof of a dangling record, so run the check again.
- No CNAME: the name has no CNAME, so this classic vector does not apply.
- Skipped: slow hosts used up the time budget. Run the remaining names again.
CSV and JSON exports use the codes vulnerable, edge_case, not_claimable, dangling, in_use, cname_unrecognized, dns_error, no_cname and skipped, in that order.
Frequently asked questions
What is a subdomain takeover?
A DNS record, usually a CNAME, still points to a cloud resource that was deleted, such as a GitHub Pages site, an S3 bucket or an Azure app. Anyone who creates a resource with that name on the same service then serves their own content on your subdomain, under your domain's reputation and often with access to its cookies.
How do I fix a vulnerable subdomain?
Delete the dangling DNS record, or reclaim the resource on the service yourself. Removing the record is the safer choice when the subdomain is no longer used. Make DNS cleanup part of decommissioning any cloud resource.
How do I find all my subdomains to check?
Export the records from your DNS provider, which is the most complete source. Certificate transparency logs and passive DNS also reveal names; the DNS Mapper helps discover subdomains, and the DNS Record Lookup shows each name's records.
Does "no takeover signal" mean the subdomain is safe?
Not necessarily. This tool follows the CNAME chain and matches it against 39 services from its fingerprint database. Takeovers through NS or MX records, services not in the list, or A records pointing to released cloud IP addresses are not detected. Treat the result as a first pass.
Is it legal to check subdomains I do not own?
The check only makes DNS queries and fetches the public home page, like a browser would. Still, only assess domains you own or are authorized to test, and never claim a resource on someone else's subdomain: report it through their security contact or bug bounty program instead.