Skip to content

We value your privacy

We use analytics cookies to understand how the site is used and to improve it. Privacy policy

SubAnalyzer

Subdomain takeover: how it happens and how to prevent it

How dangling CNAME, NS, A and MX records lead to subdomain takeover, what attackers can do with them, and how to find and fix them

Updated (11 min read)

Subdomain takeover happens when an attacker gains control of a resource that your subdomain still points to. A team deletes a cloud app, closes a service account, or lets a domain expire. The DNS records stay behind. Someone else claims the abandoned destination, and your DNS sends traffic to them.

Dangling CNAME records are a common route, but the same mistake can affect IP addresses, DNS delegations, and email infrastructure. What the attacker gains depends on which reference was left behind.

How dangling CNAMEs enable subdomain takeover

A CNAME (Canonical Name) record makes one DNS name an alias for another. Organizations use these records to connect branded subdomains to cloud platforms and third-party services.

For example, a team might connect its help site to an Azure web app:

help.example.com.  3600  IN  CNAME  example-help.azurewebsites.net.

The browser keeps help.example.com in its address bar. DNS uses the Azure hostname to find the server.

Later, the team moves its help site and deletes the old app. If the CNAME remains, it points to a resource that no longer exists. That is a dangling CNAME.

If another account can claim the abandoned resource and serve traffic for help.example.com, a takeover becomes possible. The attacker does not need access to your DNS account. Your existing record already directs visitors to the destination they now control.

The record never changes, only what answers at the other end of it. Once the app is deleted its name is free, and whoever creates an app with that name serves their own page at help.example.com, padlock included.

Provider protections matter. Name reservations and domain ownership checks can prevent exploitation, so a broken destination alone does not prove that a subdomain can be taken over.

How attackers find and claim abandoned destinations

Attackers discover subdomains through public records and scanning tools, then inspect their destinations for signs of abandoned resources.

Two signals are especially useful:

  • The target no longer resolves. DNS returns NXDOMAIN, meaning the queried name does not exist. For some services, this indicates that a deleted resource's name may be available again.
  • The service returns a missing-resource message. Some platforms answer web requests even for unused names. S3 can return NoSuchBucket, while other services display their own unclaimed-site pages.

The attacker then determines whether the provider allows another account to claim the resource or custom domain. Error messages are clues, not proof. The can-i-take-over-xyz project documents service-specific behavior and exceptions.

If the destination can be claimed, the attacker can publish content that visitors reach through the victim's subdomain.

Why HTTPS may still work

A takeover can also let an attacker obtain a valid HTTPS certificate. If they can serve the required validation response at the affected hostname, they may satisfy a certificate authority's domain-control check. Let's Encrypt documents this process in its HTTP-01 challenge.

Issuance depends on the hosting setup and certificate restrictions. But HTTPS does not prove that the original organization still controls the site. It can encrypt a connection to an attacker's server under a real company subdomain.

Wildcard records can widen the exposure

A wildcard CNAME such as *.example.com can direct otherwise undefined names to the same service. If that destination is claimable, the exposure can extend across every name matched by the wildcard.

Existing DNS names and delegation boundaries affect which queries match, as defined in the DNS wildcard specification. An audit that checks only named hosts can miss this broader exposure.

One wildcard record answers for every name that has no record of its own. Once its target is claimed, all of those names serve the claimer's page. The name www.example.com has a record of its own, so the wildcard never answers for it.

Other forms of dangling DNS

The same underlying problem appears wherever DNS continues to trust something the organization no longer controls. Some variants expose a website. Others expose an entire DNS zone or the ability to receive or authenticate email.

Six records that outlived what they point to, most severe first. A dangling delegation hands over a whole subzone. The others hand over one name's website, its traffic or its email.

CNAMEs pointing to expired domains

A CNAME can point to a hostname under an ordinary registered domain rather than a cloud service. If that domain expires and becomes available for registration, someone else can register it and control the destination.

For example, help.example.com might still point to support.old-vendor.example. Losing control of the vendor domain can expose every alias that depends on it, even if the original hosting account remains untouched.

Dangling NS delegations

NS (Name Server) records can delegate a subdomain to another set of DNS servers. If the delegated DNS service disappears, but the parent zone retains the delegation, an attacker may be able to claim the abandoned service or a domain used by its nameservers.

This is the most severe form in terms of potential control. An attacker who gains effective authority over team.example.com can publish DNS records throughout that delegated zone, including website destinations, mail routing, and verification records. That does not automatically give them control of example.com.

Not every abandoned delegation is claimable. DNS providers may reserve nameserver assignments or apply other protections. AWS describes both safeguards and remaining failure cases in its Route 53 dangling delegation guidance.

A records pointing to released cloud IP addresses

An A record maps a hostname directly to an IPv4 address. If a team releases a cloud IP address but leaves the record in place, a later customer assigned that address may receive traffic intended for the original service.

The new customer does not necessarily get to choose the address. The risk comes from address reuse combined with stale DNS. A successful DNS lookup will not reveal the ownership change. AWS warns that a record left pointing at a released Elastic IP address is a dangling DNS record that can be taken over.

MX records pointing to expired domains

MX (Mail Exchange) records identify the servers that receive email for a domain. If an MX destination uses a domain that expires and is re-registered, the new owner may be able to operate the referenced mail server and receive messages intended for the victim.

The impact depends on mail-server selection, fallback behavior, and transport security policies. It can include exposure of messages or password-reset emails. This is a mail-routing problem, not automatic control of the victim's website or outgoing email. The routing behavior is defined in the SMTP specification.

Abandoned SPF and DKIM dependencies

SPF (Sender Policy Framework) identifies servers authorized to send email using a domain. Its policy is published in a TXT record and can depend on another domain through include: or redirect=. If an attacker gains control of that dependency, they may be able to make their sending servers pass SPF for the affected domain. See the SPF specification.

DKIM (DomainKeys Identified Mail) verifies email signatures using public keys published through DNS. Organizations often use a CNAME at a selector name such as selector._domainkey.example.com to let a provider manage the key. If the destination domain or provider account becomes claimable, and the attacker can control the key returned through it, they may be able to sign email as the affected domain. See the DKIM specification.

These attacks require control over the relevant email dependency. Taking over a normal website CNAME does not by itself let an attacker edit the victim's MX, SPF, or DKIM records.

What a takeover can expose

Cookies and sessions

A cookie set with Domain=example.com is eligible to be sent to subdomains, including a hijacked help.example.com, when its other conditions match. If it contains a reusable session token, the attacker may be able to impersonate the user.

Secure requires HTTPS. HttpOnly prevents JavaScript from reading the cookie, but does not stop the browser from sending it to a matching server.

Host-only cookies, created by omitting the Domain attribute, limit this exposure. The __Host- prefix adds browser-enforced restrictions that prevent domain-wide scope. See MDN's cookie documentation.

Phishing under a familiar name

A fake login page at support.example.com has an advantage over a lookalike domain: the address really belongs to the organization. With valid HTTPS, neither the hostname nor the certificate necessarily reveals the change in control.

The attacker gains a convincing place to ask employees or customers for credentials.

OAuth and single sign-on

OAuth is an authorization protocol often used alongside single sign-on. Redirect URLs tell an authorization server where to return a browser after authorization.

If an application accepts redirects to any subdomain, a takeover may let an attacker receive authorization codes or tokens. An abandoned subdomain that remains registered as an exact callback URL can create the same problem.

A stolen code is not automatically usable. Client authentication and PKCE, which binds the code to the initiating client, can prevent redemption. The OAuth security best current practice requires exact redirect matching, with a narrow exception for native-app localhost ports.

Malicious downloads and scripts

If a trusted application loads JavaScript from the hijacked host, an attacker may be able to replace that script. Documentation and updaters may also keep directing users to compromised downloads. Signature and integrity checks can limit the damage.

Related research shows how long these dependencies can survive. In February 2025, watchTowr Labs reported registering about 150 abandoned S3 buckets that received more than 8 million requests over two months. Requests included software updates, JavaScript files, and deployment templates.

Those bucket names were written directly into software, documentation, deployment playbooks, and build scripts, so this was not a DNS takeover. The shared failure was continued trust in a resource after its original owner abandoned it. See watchTowr's original report.

How to detect subdomain takeover risks

Start with records exported from every DNS provider you use. Public subdomain discovery helps find overlooked assets, but it cannot guarantee a complete inventory.

  1. Audit CNAMEs, including wildcards. Follow each chain, investigate NXDOMAIN responses and service-specific error pages, and match destinations to active resources in your accounts. Check registration and ownership of any external domains in the chain.
  2. Review NS delegations. Confirm that each delegated zone exists in an account you control and that its assigned nameservers match the parent delegation. Investigate abandoned DNS accounts, stale nameserver assignments, and expired nameserver domains.
  3. Match A records to current IP allocations. Compare addresses with your cloud and hosting inventories. A responding server is not proof of ownership. Include IPv6 AAAA records in the same review.
  4. Check MX destinations. Verify that every primary and backup mail destination belongs to an active provider or infrastructure you control. Check the registration status of the domains behind those hostnames.
  5. Trace SPF dependencies. Review include:, redirect=, and other DNS-dependent terms, including nested references. Confirm that each still belongs to an authorized sender.
  6. Review DKIM selectors. Use your DNS inventory and email-provider configuration to find active and retired selectors. Follow selector CNAMEs and confirm that their destinations remain tied to your organization.
  7. Resolve ownership gaps. Remove unused records or repoint them to verified resources. Investigate destinations that already serve unexpected content or belong to an unfamiliar account.

A missing destination, a claimable destination, and one already controlled by someone else are different findings. Automated checks help prioritize investigation, but ownership records are essential.

How to prevent and fix subdomain takeover

Remove references before releasing resources. Delete or repoint DNS before deleting an app, releasing an IP address, closing a provider account, or allowing a domain to expire. Remove parent NS delegations before deleting child zones. Allow cached records to expire according to their time to live (TTL) before releasing the destination.

Delete the app first and the record points at a free name until someone notices. Remove the record first and let cached copies expire, and nothing points at the name when it is freed.

Keep an owner for every dependency. Record the responsible team, provider, account, and resource. Include DNS and email cleanup when replacing vendors or closing cloud accounts.

Use provider protections. Azure App Service supports asuid TXT verification records that help prevent another subscription from binding your custom domain. Azure DNS alias records also prevent dangling references for supported resource types. Check the documented service-specific behavior.

Retire application and email trust. Remove unused OAuth callbacks, script URLs, download links, SPF dependencies, and DKIM selectors. Coordinate email changes with the active provider so legitimate mail continues to work.

Re-scan and repeat the broader audit. A resource deleted tomorrow can create a new exposure. Monitor domain renewals and repeat ownership checks after infrastructure changes.

If someone already claimed a destination, removing the record is only the first step. Investigate traffic and any credentials, sessions, messages, or files that may have been exposed. OWASP's prevention guide includes response guidance.

What SubAnalyzer checks

Every SubAnalyzer scan automatically checks the CNAME targets of the subdomains it finds, including wildcard CNAMEs. Coverage includes 36 services: 15 Azure services, S3 and Elastic Beanstalk on AWS, and 19 other platforms.

The checks use two methods:

  • DNS checks flag targets returning NXDOMAIN for the supported Azure services, Elastic Beanstalk, and Discourse.
  • Web response checks look for service-specific unclaimed messages on most other supported platforms, including S3's NoSuchBucket, WordPress.com's "Do you want to register," and Ghost's "Site unavailable."

The checks account for known naming exceptions, including reserved regional Azure Web Apps names and the claimable name.region.elasticbeanstalk.com format.

Three CNAMEs, three outcomes. The Azure name is gone from DNS and the S3 bucket no longer exists, so anyone could claim either one. The Ghost site is live.

A free scan shows a red "Takeover risk" marker beside each flagged subdomain and a count of takeover risks. Paid plans also show the affected service and CNAME destination to help you investigate and fix the record.

These findings cover supported CNAME risks only. They do not check expired external domains, NS delegations, released IP addresses, MX destinations, or SPF and DKIM dependencies. Those forms need their own audit. For details on discovery, see how our subdomain scanner works.

Monitoring can re-scan your domain daily, weekly, or monthly. When something changes, SubAnalyzer sends one email with takeover risks listed first. Quiet days send nothing. One monitored domain is free, and paid plans support up to 10.

Scan your domain to check for CNAME-based subdomain takeover risks.

Sources

← All articles