Cybersecurity glossary
What is a Subdomain Takeover?
Learn what a subdomain takeover is, how dangling DNS records point to claimable third-party services, and which verification and cleanup practices reduce takeover risk.
Definition
A subdomain takeover is the hijacking of a subdomain because its DNS still points to a deprovisioned or claimable external service that an attacker can register or control.
Why abandoned DNS becomes attack surface
A subdomain takeover happens when DNS outlives the service it was meant to describe. The record still tells users to go somewhere, but the destination is no longer under the organization’s control and can sometimes be claimed by anyone who understands the provider’s onboarding flow.
That is why takeover bugs are so common during replatforming, marketing-site cleanup, cloud decommissioning, and SaaS churn. Teams remove the app and consider the work done, while the DNS record remains quietly inviting traffic to a now-claimable location.
The ingredients of a takeover condition
Not every stale record is exploitable, but successful subdomain takeovers usually share the same basic pattern: a live DNS pointer, a missing resource, and a provider willing to let someone else bind the name.
Dangling reference
A DNS record still points at a cloud, SaaS, CDN, or hosting destination that no longer belongs to the original owner.
Claimable target
The provider allows a different tenant or account to create a resource at that destination or attach the custom domain.
Traffic still follows DNS
Users, crawlers, or integrations continue resolving the real subdomain and reaching the attacker-controlled endpoint.
Verification gaps matter
Providers with strong domain-verification controls reduce takeover opportunities, while weak or missing proof flows make them easier.
How a subdomain takeover typically happens
A team decommissions an external service
The application, page, or cloud resource is deleted or detached during cleanup or migration.
The DNS record is left behind
A CNAME, A, or similar record still directs the organization’s subdomain toward the old service.
An attacker identifies the dangling target
They scan for provider-specific fingerprints indicating the destination is unclaimed or misbound.
The provider resource is claimed
The attacker creates a new tenant resource or binds the abandoned custom domain if verification rules allow it.
Traffic begins reaching attacker content
Visitors, API calls, or automated trust relationships may now land on infrastructure controlled by the attacker.
Remediation requires DNS and provider cleanup
The defender removes or fixes the DNS record and, when possible, reclaims or verifies the domain on the platform.
Common subdomain-takeover patterns
The exact exploitation path depends on the platform, but the operational smell is consistent: DNS still points somewhere that no longer maps cleanly to the organization’s active asset inventory.
| Pattern | Why it happens | Potential impact |
|---|---|---|
| Deleted SaaS microsite | Marketing or support content is removed, but the custom-domain CNAME stays in DNS. | Attackers can host phishing or brand-abuse content under a trusted company subdomain. |
| Deprovisioned cloud app | The application is torn down before its DNS entry or provider verification state is retired. | Users and internal tools may resolve to attacker-controlled infrastructure. |
| Unverified custom-domain workflow | The provider accepts domain binding without durable proof that the same organization still owns the namespace. | Another tenant may successfully attach the domain after a configuration change or outage. |
| Forgotten integration endpoint | A subdomain created for a partner or temporary campaign remains after the partnership or campaign ends. | Dormant trusted endpoints become pivot points for impersonation or tracking abuse. |
Prevention habits that actually help
Subdomain takeover prevention is mostly asset hygiene plus provider-aware verification. The DNS record should never be the only artifact that outlives a service teardown.
- Tie DNS records to an inventory entry or owning service so decommissioning workflows include DNS cleanup by default.
- Use provider verification features such as TXT-based ownership tokens wherever available and keep those protections in place.
- Continuously scan for dangling aliases and provider fingerprints rather than relying on one-off reviews.
- Remove or repoint custom-domain records before deleting the underlying third-party resource whenever possible.
- Review wildcard or shared-zone practices carefully because they can hide stale integrations under broad naming patterns.
- Track vendor-specific reuse behavior so teams know whether a deleted destination becomes immediately claimable.
- Watch certificate issuance and content changes on low-traffic subdomains that may not have active human owners anymore.
- Treat takeover findings as production risk even when the vulnerable subdomain seems unimportant, because trust often follows the brand, not the traffic volume.
Why takeover impact is often underestimated
A subdomain that looks minor to the organization can still be valuable to an attacker because it inherits trust from the parent brand. Users are more likely to believe content, cookies may scope broadly in badly designed systems, and allowlists sometimes include whole domain patterns rather than carefully bounded hosts.
The exploitation window can also persist quietly. If the vulnerable subdomain is low traffic, nobody notices until it becomes part of a phishing campaign, an OAuth redirect abuse chain, or a supply-chain style trust anchor for something else.
The practical takeaway
A subdomain takeover is what happens when DNS still points to a service that your organization no longer controls and someone else can claim it. The vulnerability is created by drift between DNS and asset ownership.
The practical defense is disciplined cleanup plus provider verification. If a service is gone, its DNS should not still be advertising a path to it.
Related security terms
Dangling DNS Record
The stale DNS reference is the root condition that makes many takeovers possible.
CNAME Record
Subdomain takeovers often start with a CNAME still pointing at a service that no longer belongs to the organization.
TXT Record
TXT-based verification records can help prove domain ownership and block some takeover paths.
Domain Hijacking
Subdomain takeover is narrower than full domain hijacking but can still redirect real user traffic.
DNS Zone
The vulnerable record usually lives in an otherwise legitimate production DNS zone.
Frequently asked questions
What causes a subdomain takeover?
The usual cause is a DNS record that still points to a service which has been deleted, released, or was never fully verified, allowing someone else to claim it.
Are subdomain takeovers only about CNAME records?
No. CNAMEs are common, but other record patterns and provider behaviors can also produce claimable dangling references.
Why are SaaS and cloud platforms often involved?
Many platforms let customers map custom domains to provider-hosted resources. If the customer removes the resource but leaves DNS behind, another party may be able to claim the destination.
Can HTTPS still work during a subdomain takeover?
Sometimes yes, especially if the provider allows the attacker to obtain or serve certificates for the claimed custom domain through its normal workflow.
How do verification TXT records help?
They make it harder for a different account or tenant to prove ownership of the custom domain and bind it to a new resource.
Is a dangling DNS record always exploitable?
No. Exploitability depends on the target provider’s domain-claim rules, reuse behavior, and verification requirements.
References
Explore authoritative guidance and frameworks related to subdomain takeover.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.