# Subdomain Takeover: How Dangling DNS Records Get Hijacked — and How to Find Them

> A subdomain takeover happens when a DNS record still points at a service you no longer own. Here's how dangling CNAMEs get hijacked, what an attacker can do with one, and how to detect and close them.

- URL: https://www.pyalm.com/blog/subdomain-takeover-explained-detect-prevent
- Author: Fadhil Abdulla
- Category: Pyalm Guard
- Published: 2026-07-07
- Updated: 2026-07-07

---

A subdomain takeover is one of the quietest ways to lose control of part of your domain. Nobody breaks into a server. No password is stolen. A DNS record simply keeps pointing at a service you stopped using — and someone else claims the other end.

## What a subdomain takeover actually is

Most subdomains don't resolve to your own servers. They **CNAME** to a third-party service: a marketing site on a SaaS host, a docs portal, a status page, a storage bucket, a support widget. The record says "for `help.example.com`, go ask this provider."

The problem starts when you decommission that service but **leave the DNS record behind**. Now `help.example.com` points at a hostname the provider no longer has assigned to anyone. That's a **dangling CNAME**. If the provider lets a new customer claim that hostname, whoever claims it now controls content served at *your* subdomain.

## Why it matters more than it looks

A subdomain you forgot about is still *your* domain to a browser, a user, and often a cookie. An attacker who takes one over can:

- **Phish with a real domain.** A login page on `portal.example.com` is far more convincing than any lookalike domain.
- **Steal cookies and tokens** scoped to `*.example.com`, depending on how yours are set.
- **Bypass allowlists** — CSP `frame-ancestors`, CORS rules, and OAuth redirect allowlists that trust your own subdomains now trust the attacker.
- **Damage reputation** by hosting spam or malware under your brand.

## How to find dangling records

Detection is really two questions asked across every subdomain you have:

1. **Do I even know all my subdomains?** Enumerate them from certificate-transparency logs, passive DNS, and a brute-force wordlist. You can't check records you don't know exist.
2. **Does each CNAME still resolve to a claimed resource?** For every subdomain that CNAMEs to a third party, confirm the target still exists and is still yours. A CNAME that resolves to a provider's "no such site" fingerprint is the red flag.

Doing this by hand across a real domain is tedious, which is exactly why forgotten records survive. [**Pyalm Guard**](https://www.pyalm.com/products/guard) automates both halves: it enumerates subdomains passively and by brute-force, then flags dangling CNAMEs as subdomain-takeover risk in a severity-ranked report — [run it on a domain you own](https://guard.pyalm.com).

## How to prevent them

- **Delete the DNS record the moment you retire a service** — make it a step in your decommissioning checklist, not an afterthought.
- **Enumerate on a schedule.** Attack surface grows quietly; a quarterly sweep catches records that outlived their service.
- **Prefer records you control** for anything sensitive, and avoid wildcard CNAMEs that mask individual dangling entries.
- **Claim before you cancel** where a provider allows it, so there's no window between "you stopped paying" and "the hostname is free."

The fix is almost always a one-line DNS deletion. The hard part is *knowing which line* — and that's a discovery problem, not a security-genius problem.

## Related reading

[Assess your attack surface with Pyalm Guard](https://www.pyalm.com/products/guard) | [Introducing Pyalm Guard](https://www.pyalm.com/blog/introducing-pyalm-guard-security-posture-assessment) | [SPF, DKIM & DMARC explained](https://www.pyalm.com/blog/spf-dkim-dmarc-explained-stop-email-spoofing) | [HTTP security headers guide](https://www.pyalm.com/blog/http-security-headers-guide-hsts-csp)