Subdomain Takeover Checker

Check up to 50 hostnames for subdomain takeover risk. Follows each CNAME chain over DNS-over-HTTPS, flags dangling CNAMEs whose target no longer exists, and matches targets against 57 services rated by can-i-take-over-xyz. Free, runs in your browser.

Before you start

Passive DNS only. This page sends DNS queries to public resolvers and compares the answers with a list of known services. It never contacts the hostnames, never tries to register or claim anything, and never exploits a finding. Only test domains you own or are authorised to test. Results are leads that need manual confirmation, not proof.

Paste the subdomains you want to check and click Check hostnames.

How to use it

  1. Paste the hostnames you want to check, one per line: shop.example.com, https://blog.example.com/post or admin@help.example.com all work. Wildcards like *.example.com are checked at the base name. Up to 50 hostnames run per click, 8 at a time.
  2. For each name the page asks Cloudflare's public DNS-over-HTTPS resolver (Google if Cloudflare fails or returns SERVFAIL) for its A records, follows every CNAME hop, and reads the A and AAAA records of the final target. NXDOMAIN (name does not exist), NOERROR with no address, and SERVFAIL or timeouts are kept apart because they mean different things.
  3. Each CNAME target is matched against 57 services from the can-i-take-over-xyz list, along with that list's verdict for the service: vulnerable, edge case or not vulnerable.
  4. Read the verdict. LIKELY: the CNAME points at a takeover-prone service and the target no longer exists, so fix it first. POSSIBLE: an edge-case service with a missing target, or a takeover-prone service that still resolves, where the provider's page has to be checked by hand. DANGLING: the target is gone but the provider isn't known to be claimable, so remove the stale record anyway. OK, NO_RECORD and ERROR mean nothing to fix, nothing there, and retry.
  5. To fix a finding, delete the DNS record or re-create the resource at the provider so it is yours again. Remove DNS records before you delete cloud resources, not after.

Need proof, not just DNS?

A browser page can only see DNS. The Subdomain Takeover Checker on Apify also fetches each hostname over HTTP and HTTPS and matches the provider's "no such app / bucket / site" page against the can-i-take-over-xyz body fingerprints, can discover subdomains from certificate transparency logs, and checks thousands of hosts per run with CSV or JSON export ($2 per 1,000 hosts). It is passive too: it never registers or claims anything.

Related tools

Look up every record type for a name with DNS Lookup, confirm a deleted record is gone from public resolvers with the DNS Propagation Checker, find forgotten subdomains in certificate logs with the SSL Certificate Checker, and see which cloud owns a target IP with Cloud IP Lookup or ASN IP Lookup.

FAQ

What is a subdomain takeover?

A subdomain takeover happens when a DNS record such as shop.example.com still points at a third-party service (a cloud app, storage bucket, CDN or hosted page) after the resource there was deleted. If the service lets anyone create a resource with that name, an attacker can claim it and serve their own content on your subdomain, which enables phishing, cookie theft and reputation damage.

What is a dangling CNAME?

A CNAME record whose target no longer exists. DNS answers NXDOMAIN for the target, so the subdomain points at nothing. It is the classic sign of a deprovisioned cloud resource, and on services listed as vulnerable by can-i-take-over-xyz it often means the subdomain can be taken over.

How do I fix a subdomain takeover risk?

Delete the stale DNS record, or re-create the resource at the provider so it is under your control again. To stop it happening again, remove DNS records before deleting cloud resources, keep an inventory of CNAMEs that point at third parties, and re-check after every decommission.

Is it safe and legal to check for subdomain takeover?

This page only makes ordinary public DNS lookups through Cloudflare or Google, the same queries any browser makes, and it never contacts the hosts or tries to claim anything. Even so, only test domains you own or are authorised to test, and never register a resource on someone else's dangling record. Report it to their security contact instead.

Why can't this page confirm a takeover over HTTP?

Confirmation means loading the subdomain and reading the provider's error page, for example NoSuchBucket or There isn't a GitHub Pages site here. Browsers block one website from reading another site's response (the same-origin policy and CORS), so a client-side page can only see DNS. The Apify actor linked above runs server-side and does the HTTP body check.