Domain guide

Subdomain Takeover Scan Guide

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.

Open Subdomain Takeover Scan All guides

Beginner explanation

What this tool helps you understand

Subdomain Takeover Scan helps you check public domain signals behind the search intent "subdomain takeover scanner".

Technical note

How to use the result safely

For production work, compare the XGM result with authoritative DNS, hosting, registrar or provider data before making critical changes.

Workflow

How to use Subdomain Takeover Scan

Follow this simple workflow before copying output or making production changes.

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.

Use cases

When to use this guide

Check a public signal before or after a configuration change.
Troubleshoot what users, mail systems or browsers see from the outside.
Collect evidence before escalating to a provider, registrar or colleague.

Common mistakes

What to avoid

Forgetting DNS and routing data can be cached.
Assuming one clean result means the whole system is secure.
Changing production settings without rollback notes.

FAQ

Subdomain Takeover Scan FAQ

Quick answers for users arriving from search or comparing tools.

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.

Run the tool

Ready to check it?

Open the live XGM tool and use this guide while reviewing the result.

Open Subdomain Takeover Scan →

Related tools

Continue the subdomain takeover scanner workflow

Open nearby XGM tools that help complete the same technical check.

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.

Related guides

More domain guides

Domain