Subdomain Takeover Checker
Check if subdomains point to cloud services that no longer exist. Catches subdomain takeover risks across S3, GitHub Pages, Heroku, and more. No server.
0
Scanned
0
Potentially vulnerable
0
Check manually
| Subdomain | Status |
|---|
Disclaimer: Free tool provided “as is” by MonitorGiant. No warranty or liability for any data loss, security issues, or infrastructure problems arising from use of this tool. Results are for informational purposes only. · A Free Tool by MonitorGiant
How Subdomain Takeover Checker works
Subdomain takeovers happen when a CNAME record points to an external service (like AWS S3, GitHub Pages, or Heroku) that has since been deleted. An attacker can claim that service and serve content under your domain. This tool detects those dangling CNAMEs entirely from your browser.
- 1
Enter the root domain to scan
Type a domain (e.g. example.com) and the tool builds a wordlist of ~35 common subdomains: dev, staging, api, mail, blog, cdn, assets, and more.
- 2
CNAME records resolved via DNS-over-HTTPS
For each subdomain, the tool queries the Cloudflare DoH resolver. Only subdomains with CNAMEs are flagged for further analysis — subdomains with A/AAAA records directly are skipped.
- 3
CNAME targets matched against known-vulnerable patterns
Each CNAME destination is compared against a built-in list of known-vulnerable provider patterns: *.s3.amazonaws.com, *.github.io, *.herokudns.com, *.azurewebsites.net, *.fastly.net, and more.
- 4
Risk level assigned
Subdomains are flagged as "Potentially vulnerable" if the CNAME matches a known provider pattern, or "Check manually" if an unexpected CNAME was found that needs human verification.
- 5
Results shown with recommended action
Each flagged subdomain shows the full CNAME chain, matched provider, risk level, and recommended fix — typically removing the dangling DNS record via your DNS provider.
DNS lookups go directly from your browser to Cloudflare DoH. Domain names you scan are sent to Cloudflare as part of the lookup — the same as any standard DNS resolver. No scan results or domains are logged by MonitorGiant.
Wondering how to check if your subdomain is vulnerable to takeover? Subdomain takeovers happen when a CNAME still points to a cloud service — an S3 bucket, GitHub Pages site, or Heroku app — that no longer exists. Because the service has been deleted, an attacker can register it and serve their own content under your domain. This tool scans the most common subdomains (dev, staging, api, cdn, blog, mail, and more) for dangling CNAMEs in seconds, directly from your browser — no installation required.
Frequently asked questions — Subdomain Takeover Checker
What is a subdomain takeover vulnerability?
A subdomain takeover occurs when a subdomain (e.g. staging.example.com) has a CNAME record pointing to a third-party service (like GitHub Pages, Heroku, or Fastly) that no longer has an active account claiming that hostname. An attacker can register on that service and serve content from your subdomain — including phishing pages or malware — while appearing to be your domain.
Which services are most commonly affected by subdomain takeovers?
Any SaaS platform that lets users claim custom subdomains via CNAME is potentially vulnerable when the account is deleted but the DNS record is not removed. Common targets include GitHub Pages, Heroku, Fastly, Pantheon, Unbounce, Shopify, Amazon S3, Microsoft Azure, and Netlify. This tool checks CNAMEs against a database of known vulnerable provider patterns.
How do I fix a subdomain takeover vulnerability?
The safest fix is to delete the dangling CNAME record from your DNS zone immediately. If you still need the subdomain for a future service, either keep the service account active and configured, or point the CNAME somewhere you control (like a maintenance page). Never leave a CNAME pointing at an external service without an active account on that service.
What is a dangling CNAME record?
A dangling CNAME is a DNS record that points to an external hostname that either no longer exists or resolves to an unclaimed resource. For example: staging.example.com → myapp.herokuapp.com, where the Heroku app has been deleted. The CNAME still resolves, but the destination is available for anyone to claim.
How many subdomains does this tool scan?
The tool scans a curated wordlist of common subdomain prefixes (www, mail, blog, api, staging, dev, app, cdn, shop, and many more). It performs parallel DNS-over-HTTPS lookups for each prefix, so the full scan completes in a few seconds. The wordlist focuses on high-risk prefixes likely to have been pointed at third-party services.
Comments & Feedback
Found a bug? Have a suggestion? We'd love to hear from you.
Related Tools
From the makers of this tool
Need deeper observability?
MonitorGiant tracks real-time AI performance, infrastructure health, and system reliability — far beyond what free utilities can show.