Subdomain Takeover in 2026: How a Forgotten DNS Record Lets Strangers Publish Under Your Name, Why Deleting the Cloud Resource First Is the Mistake, and How to Find Dangling Records Before Attackers Do
- Internet Pros Team
- September 16, 2026
- Networking & Security
Most businesses think of their domain name as a single asset they renewed last year. In practice it is a sprawl of subdomains: a marketing landing page on one platform, a help centre on another, a staging site on a cloud app service, a status page, a store, a campaign microsite from three years ago. Each one is a DNS record pointing somewhere else. When the thing it points to is deleted but the record is not, the name is left dangling, and anyone who can claim the abandoned resource can publish content on your domain. That is a subdomain takeover, and in 2026 it remains one of the cheapest, quietest ways to borrow a trusted brand.
How a Dangling Record Happens
The pattern is almost always the same. Someone creates a cloud resource with a provider-assigned hostname, such as a storage bucket website, an app service, a GitHub Pages site or a hosted help desk. To give it a friendly address they add a CNAME record, so that promo.example.com points at the provider hostname. Months later the campaign ends and the resource is deleted to save money. Nobody touches DNS, because DNS lives in a different console, often owned by a different team.
The CNAME now points at a name the provider considers free. On many platforms the resource name is first come, first served. An attacker who registers the same bucket, app or site name inherits the traffic, and every visitor to promo.example.com sees whatever the attacker chooses to serve, under your domain, in the address bar, often with a valid HTTPS padlock.
A subdomain takeover is not a hack of your servers. The attacker never touches your infrastructure. They simply accept an invitation that your own DNS is still sending out.
Why It Is Worse Than a Defaced Page
A hijacked subdomain inherits the trust your organisation built for the parent domain, and a surprising amount of security configuration is written in terms of that trust.
What an Attacker Gets Along With the Name
- Convincing phishing. A login page on
account.example.compasses the check users are taught to perform: look at the domain. - A real certificate. Because the attacker controls the content served at the name, automated certificate authorities will issue a certificate for it after an ordinary HTTP validation.
- Session cookies. Cookies scoped to
.example.comare sent to every subdomain, including the hijacked one. - Allow-list abuse. CORS policies, Content Security Policy rules and OAuth redirect lists that trust
*.example.comnow trust the attacker too. - Email reputation. If the takeover includes mail records or a sending service, messages can pass SPF checks written for your brand.
That last point is not theoretical. In early 2024 Guardio Labs documented a campaign it named SubdoMailing, in which spammers took over thousands of abandoned subdomains belonging to well-known brands and universities and used their inherited SPF permissions to send millions of phishing and scam emails that sailed through filters.
The Common Varieties
| Record type | What dangles | Typical sign |
|---|---|---|
| CNAME to a SaaS or PaaS name | Deleted app service, bucket website, Pages site or hosted help desk | Provider error page such as NoSuchBucket or a site not found message |
| A record to a cloud IP | Released elastic or public IP that returns to the shared pool | The address later answers with someone else’s server |
| NS delegation | A subdomain or whole domain delegated to a DNS host where the zone was deleted | Name servers answer REFUSED or SERVFAIL for the zone |
| MX or SPF include | Retired mail or marketing sender still authorised in DNS | Include points at a domain or account nobody owns any more |
The delegation case is the most severe, because the attacker gets the whole zone rather than one name. Research published in 2024 by Eclypsium and Infoblox under the name Sitting Ducks estimated that more than a million registered domains were exposed to this kind of hijack through DNS providers that let anyone create a zone for a domain they do not own, and found criminal groups had already been exploiting it for years.
What Providers Have Changed
Cloud platforms have spent the last few years closing the easiest paths. Azure App Service asks for a domain verification TXT record before a custom hostname can be bound, and Azure DNS offers alias records that disappear with the resource they point to. Amazon CloudFront refuses to attach an alternate domain name without a certificate proving control of it. GitHub lets organisations verify custom domains so that nobody outside the account can claim them for a Pages site.
These protections help, but only when they are used, and only on the platforms that offer them. Storage bucket names, many smaller SaaS tools and plenty of legacy records remain first come, first served. The community project can-i-take-over-xyz keeps a running list of which services are still vulnerable and what their fingerprints look like.
Finding Your Own Dangling Records
You cannot protect subdomains you do not know about, and attackers are enumerating them already. Start from the same sources they use.
- Export every zone. Pull all records from each DNS provider you use, including the ones a marketing agency set up years ago.
- Search Certificate Transparency logs. Every public certificate is logged, so a tool such as crt.sh reveals subdomains that were issued certificates, even ones missing from your inventory.
- Resolve and fingerprint. For each CNAME, check whether the target still exists and whether the response matches a known unclaimed-resource page. Open-source scanners such as dnsReaper and the takeover templates for nuclei automate this.
- Check delegations and mail. Confirm every NS record answers authoritatively and every SPF include still belongs to a service you pay for.
- Run it on a schedule. A one-off audit decays within months. A weekly scan with alerts catches a record the week it starts to dangle.
Fixing the Process, Not Just the Record
The single most useful rule is about order: remove the DNS record first, then delete the resource. When the order is reversed, even briefly, the name dangles. When it is followed, there is never a window.
Beyond that, the durable fixes are organisational. Manage DNS records in the same infrastructure-as-code definition as the resources they point to, so that tearing one down tears down the other. Give every subdomain an owner and a purpose in an inventory. Use provider verification records and alias records wherever they exist. Avoid wildcard DNS entries that point at shared platforms, and narrow cookie scopes and allow-lists from *.example.com to the specific hosts that actually need them, so a single lost subdomain cannot unlock the rest.
If you do find a takeover in progress, remove the record immediately, revoke any certificates issued for the name through your certificate authority, rotate session secrets if cookies were shared across subdomains, and check logs and mail reputation for what was sent while it was live.
The Bottom Line
Subdomain takeover persists because it lives in the gap between teams: the people who delete cloud resources rarely own DNS, and the people who own DNS rarely hear that a resource is gone. Closing that gap costs very little. Inventory your subdomains, scan them on a schedule, delete records before resources, and stop trusting every name under your domain by default. Your domain is your signature online; make sure nobody else is still holding the pen.
