Someone else is hosting on your subdomain

Most of the low-level stuff we write about is config you forgot to add. This one is the opposite: config you forgot to remove. It's quieter than a missing header and, when it goes wrong, a lot louder — because the attacker doesn't break into your site. They get handed a piece of it.

What a subdomain takeover actually is

Lots of subdomains don't point at your own server. They point at a third-party host with a CNAME record — help.yourdomain.com at a support-desk SaaS, status.yourdomain.com at a status-page service, a landing page at S3 or GitHub Pages, a preview app on Vercel or Netlify.

The takeover happens when you stop using that resource but leave the DNS record behind. Now the subdomain dangles— it points at a hostname on a provider where nobody owns the thing it's naming anymore. An attacker who spots it simply signs up for that provider, claims the same hostname or bucket name, and inherits your subdomain. No exploit. They filled a vacancy you left open.

Why it's worse than it sounds

How subdomains end up dangling

Nobody leaves one open on purpose. It's always cleanup that stopped one step short:

• ▪Decommissioned an app — deleted the Heroku / Vercel / Netlify project but left the CNAME pointing at it.
• ▪Tore down storage — removed an S3 bucket or GitHub Pages repo that a record still names.
• ▪Churned a SaaS — cancelled the help desk, status page, or email tool that gave you a cname.theirservice.com target.
• ▪Left an experiment lying around — a staging or preview subdomain from a spike nobody circled back to delete.

Find your own dangling records

1. 1

   List every DNS record.

   Pull your full zone from your DNS provider and look hard at the CNAME and ALIAS records. You can't secure a subdomain you've forgotten exists.
2. 2

   Check what each one points at.

   For every record aimed at a third party, confirm two things: that the target still resolves, and that you still own that resource on the provider it lives on.
3. 3

   Look for the tell.

   Load the subdomain. If it shows the provider's “no such app,” “NoSuchBucket,” or “there's nothing here yet” page, that's the flag — the record is pointing at an unclaimed slot anyone can grab.
4. 4

   Or let a scan enumerate them for you.

   Finding every subdomain by hand is the hard part. Our scan enumerates the subdomains it can discover and flags the ones sitting in a takeover-prone state, so the dangling record surfaces without you trawling the whole zone.

The fix

Once you've found a dangling record, closing it is fast — the trick is which way to close it:

• ▪Don't use the subdomain anymore? Delete the DNS record. That's the whole fix — no record, nothing to take over.
• ▪Still need it? Re-claim the resource on the provider — recreate the bucket, app, or custom-domain binding — so the record points at something you own again.
• ▪Going forward, treat decommissioning as two steps, not one: when you kill a host, delete its DNS record in the same change. The leftover record is the entire vulnerability.

While you're in the zone file, it's worth remembering that a subdomain can be abused for email too — an attacker on a subdomain you don't protect can spoof mail from it. If you haven't already, set DMARC at the domain level so the policy covers the whole tree, subdomains included.

The reason this one feels scary is that it borrows your credibility — the padlock, the name, the trust. Take away the dangling record and you take away the whole trick. It's a line of DNS you delete once, and a two-step habit that keeps it from coming back.