Subdomain Takeover Scan
Find subdomains whose DNS still points at a service that no longer serves them, before somebody else claims the name.
Related tools
- DNS LookupLook up DNS records by type, including reverse (PTR) lookups for IP addresses.
- Domain HealthOne check for DNS, email authentication, TLS, security headers and redirects, with a grade per area and a full report.
- TLS CheckerInspect a site's TLS certificate, expiry, issuer and negotiated protocol, with a renewal calendar you can download and a full report.
- DNS Migration CheckCompare what your current and your new nameservers answer, record by record, before you switch the delegation.
About this tool
Subdomain Takeover Scan looks for the DNS records everybody forgets: a CNAME left pointing at a hosting service, an S3 bucket or a help-desk after the account was closed. The record still resolves as far as the domain owner is concerned, but the name on the other end is free - and whoever registers it next serves their content on your subdomain, with your certificate story and your cookies. XGM collects candidate subdomains from certificate transparency, which means it finds what an attacker scanning the same public logs would find, and adds any names you paste in. Each candidate is resolved, and a CNAME pointing at a known provider is checked against that provider's own "no such site" behaviour. The verdict is deliberately narrow: a subdomain is called vulnerable only when there is evidence - the target does not resolve, or the provider answered with its unclaimed-name page - and the row says which. Anything else is uncertain or not checked, never quietly "safe". Scanning sends the domain name to crt.sh, which is public data, and connects to the CNAME targets from the XGM server under the same guard as every other outbound check.
A subdomain takeover starts with a record nobody removed. A name is pointed at a hosting provider with a CNAME, the site there is deleted or the account lapses, and the record stays behind pointing at a name that is now free. Whoever claims that name next serves whatever they like on your subdomain - with your cookies, your CORS rules and, to a reader, your brand.
This check collects candidate subdomains from certificate transparency, which is public, so it sees roughly what an attacker sees, resolves each name, and reports what it observed: a CNAME whose target does not resolve, or a provider answering with its own “no such site” page. Anything short of that is reported as uncertain rather than as a finding, and a name the scan did not reach is reported as not checked, never as safe.
To look at one name's records directly, use DNS Lookup; to see what the service behind it answers, HTTP Headers.
How to use it
- Enter the domain. Add any subdomains you already know about; certificate transparency does not list everything.
- Read the vulnerable rows first: each names the provider and what was observed.
- For a record you no longer use, delete it at your DNS provider - that closes the hole immediately.
- For one you still want, re-claim the name at the provider before removing anything.
- Re-run the scan after the change, and add it to whatever you do when a service is decommissioned.
FAQ
What is a subdomain takeover?
A DNS record on your domain points at a name on somebody else's service - app.example.com to a hosting platform, help.example.com to a help-desk. When the account there is closed, the record stays. The provider will hand that name to the next person who asks for it, and from then on their content is served on your subdomain: it is your domain in the address bar, your cookies if they are scoped loosely, and your reputation behind whatever appears. The fix is almost always to delete a record nobody needed any more.
Where do the subdomains come from?
From certificate transparency logs through crt.sh. Every publicly trusted certificate is logged, so every name that has ever had one is public - which is the point: an attacker looking for a dangling record on your domain starts from exactly the same list. It is not complete, because a subdomain that never had a certificate never appears, so paste any names you know about into the box as well.
Why does a row say uncertain rather than vulnerable?
Because the evidence did not settle it. A CNAME pointing at a provider is not on its own a takeover: the site may be live, or the provider may not allow a released name to be claimed by anyone else. Vulnerable is reserved for the cases with evidence - the target name does not resolve at all, or the provider returned its own unclaimed-name page - and the row says which one was observed. Calling everything that points at a provider vulnerable would make the result useless.
Does the scan try to take anything over?
No. It resolves names and, where a provider's answer is what distinguishes a live site from a free one, it makes one ordinary GET request and reads the beginning of the response. It never registers a name, never logs in anywhere, and never sends anything to the provider beyond that request. Confirming a finding by claiming the name is your decision to make, on your own domain.
I deleted the record. Am I finished?
For that subdomain, yes - the record is the whole problem, and removing it is immediate. Two things are worth doing afterwards: check whether anything still links to the name, because a dead link is better than a hijacked one, and add "remove the DNS record" to whatever you do when a service is switched off. Almost every takeover is a decommissioning step nobody wrote down.