Subdomain takeover and dangling DNS records

A subdomain takeover needs no break-in. It happens when a DNS record still points to a cloud resource that has been deleted, and someone else registers that resource name. From then on they serve content on your subdomain.

Use the Domain Health Check

How it happens

A team launches a campaign site on a hosted platform and adds a CNAME from promo.example.com to the platform's hostname. Months later the campaign ends and the site is deleted on the platform. The CNAME stays in DNS, because removing it was nobody's task.

The record now points at a name that no longer exists on the platform. If the platform lets any customer claim that name, whoever claims it receives the traffic for promo.example.com, on your domain, often with a valid certificate issued to them.

Why it matters

Content served from your subdomain inherits your reputation. Visitors and mail filters trust it, and browsers may send it cookies scoped to the parent domain. It is a convincing place to host a login page.

The risk is not theoretical or rare: it is a routine finding in security reviews precisely because it is created by ordinary cleanup, not by a mistake in configuration.

Which records are at risk

Any record that delegates a name to something you can stop controlling is a candidate.

CNAME records pointing to cloud storage, app hosting, CDN or SaaS hostnames.
A and AAAA records pointing to cloud IP addresses that have been released and can be reassigned.
NS records delegating a subdomain to a DNS zone that no longer exists.
MX records pointing to a mail service the organisation has left.

How to find dangling records

Start from the DNS zone, not from a list of sites you remember.

Export every record in the zone.
For each CNAME, resolve the target. A target that does not resolve, or resolves to a provider's not-found page, needs a closer look.
Confirm in the provider's console that the resource exists and belongs to your account.
Delete records whose target you cannot account for.
Repeat on a schedule, because new records become dangling as projects end.

What a check can and cannot conclude

From outside, a check can see that a CNAME target does not resolve or matches a pattern known to be claimable. It cannot see inside your provider account, so it cannot prove a resource is yours. A finding is a prompt to verify, not a verdict. CloudSpex reports the dangling targets it can measure and states when a target could not be assessed.

Prevention

The fix is an order of operations: remove the DNS record first, then delete the cloud resource. Make DNS cleanup a step in the decommissioning checklist, give each record an owner, and avoid wildcard records that send every unknown subdomain to a third party.

Frequently asked questions

Is a CNAME to a deleted resource always exploitable?

No. It depends on whether the provider lets another customer claim the same name. It should still be removed, because the conditions can change.

Can a takeover get a valid HTTPS certificate?

Often yes. If an attacker controls what the subdomain serves, they can usually complete domain validation for that hostname. A CAA record limits which authorities may issue, but does not prevent the takeover.

How often should DNS be reviewed for dangling records?

On a schedule and whenever a service is decommissioned. Continuous monitoring catches the cases a periodic review misses.

Use public checks as a starting point

CloudSpex reads limited public-facing signals. It does not change DNS, website, certificate, or email settings. Confirm the responsible provider and test relevant changes before applying a remediation.

Editorial details

Author and reviewer: CloudSpex. Sources: public technical standards and provider documentation relevant to the topic. Last reviewed: August 10, 2026. We update guides when the product behavior or the underlying guidance changes.