Subdomain Takeover: What It Is and How to Prevent It

Most organizations set up subdomains without thinking twice. A subdomain for the blog, another for a staging server, one more for a marketing campaign that ended months ago. Over time, some of those subdomains stop being used -- but their DNS records stick around. That gap between an active DNS record and an inactive service is exactly what attackers exploit in a subdomain takeover.

This kind of attack is more common than you might expect, and it can happen to organizations of any size. The good news is that preventing it comes down to basic DNS hygiene. Here is everything you need to know.

What Is a Subdomain Takeover?

A subdomain takeover happens when an attacker gains control of a subdomain that belongs to your domain. It does not require breaking into your DNS provider or guessing any passwords. Instead, it exploits something much simpler -- a dangling DNS record.

Here is the typical scenario. Your team sets up campaign.example.com and points it to a third-party hosting service using a CNAME record. The campaign ends, your team cancels the hosting account, but nobody remembers to delete the CNAME record from your DNS zone. The subdomain still resolves, but it no longer points to anything your organization controls.

An attacker notices this. They sign up for the same hosting service, claim the hostname campaign.example.com, and now they control the content served on your subdomain. From the outside, it looks completely legitimate -- it is still under your domain name.

Why It Is Dangerous

Subdomain takeovers are not just a theoretical concern. Once an attacker controls your subdomain, they can do real damage:

• Launch phishing attacks. A phishing page hosted on login.yourcompany.com is far more convincing than one on a random domain. Employees, customers, and partners are more likely to trust it because the address looks genuine.
• Steal cookies and session tokens. Depending on how your cookies are scoped, a hijacked subdomain may be able to read cookies set by your main domain. This can lead to session hijacking and unauthorized access to user accounts.
• Damage your reputation. An attacker could host malware, offensive content, or scam pages under your brand. Even after you regain control, the reputational harm can linger.
• Undermine email trust. If your SPF or DMARC policies are not strict enough, a taken-over subdomain could be used to send emails that appear to come from your organization.

The core issue is trust. People trust your domain, and a subdomain inherits that trust. Losing control of any part of it puts everyone who interacts with your brand at risk.

How Dangling DNS Records Happen

Dangling records are not the result of a security failure in the traditional sense. They are an operational oversight, and they are surprisingly easy to create. Here are the most common ways they appear:

• Decommissioned services. You cancel a cloud hosting account, a CDN, or a SaaS platform, but forget to remove the CNAME record or A record that pointed your subdomain to it.
• Expired trials and proofs of concept. A developer spins up a free-tier service for testing, creates a DNS record to connect a subdomain, and never cleans up after the trial ends.
• Staff turnover. The person who set up the subdomain leaves the company, and institutional knowledge about that DNS record leaves with them.
• Mergers and acquisitions. When organizations combine, DNS zones often get merged without a thorough audit. Legacy subdomains from the acquired company may point to services that no longer exist.

In each case, the pattern is the same. A DNS record continues to resolve to a destination that your organization no longer controls. That stale pointer is the vulnerability.

Which Services Are Most at Risk

Not every dangling DNS record leads to a takeover. The attacker needs to be able to claim the hostname on the destination service. Some platforms make this easy, while others do not.

Services that are commonly targeted include cloud platforms that let users bring custom domains -- website hosting providers, content delivery networks, cloud storage endpoints, and platform-as-a-service products. If the service allows anyone to register and claim a custom hostname without verifying domain ownership through a unique DNS challenge, it is a potential takeover target.

The risk is highest when the service returns a generic error page for unclaimed hostnames. That error page is essentially a signal to attackers that the hostname is available for claiming.

How to Audit Your DNS for Dangling Records

Preventing subdomain takeover starts with knowing what DNS records you have and whether they still point to services you control. Here is a practical approach:

1. Inventory all your subdomains. Start by listing every DNS record in your zone file. Pay special attention to CNAME records and A records that point to external services. Use a DNS lookup tool to check what each subdomain resolves to.
2. Verify each destination is active. For every subdomain that points to an external service, confirm that the service is still active and that your organization still controls the account. If a subdomain returns an error page, a "not found" message, or a default parking page, investigate immediately.
3. Check WHOIS and registration details. Run a WHOIS lookup on your domain periodically to make sure your registration details are up to date and the domain itself is not approaching expiry. Expired domains are another vector for takeover.
4. Run a full domain report. A Domain report gives you a consolidated view of DNS records, SSL status, and other signals that can help you spot misconfigurations and forgotten subdomains in one place.
5. Remove what you do not need. If a subdomain is no longer in use, delete the DNS record. This is the single most effective prevention measure. A record that does not exist cannot be exploited.

Make this audit a recurring task, not a one-time project. DNS zones tend to accumulate stale records over time, especially in organizations where multiple teams create subdomains independently.

Best Practices for Prevention

Beyond regular audits, there are several habits that reduce your risk of subdomain takeover:

• Delete DNS records before canceling services. Whenever you decommission a service, remove the associated DNS records first -- or at the same time. Do not leave it as a follow-up task.
• Maintain a subdomain inventory. Keep a living document or spreadsheet that tracks every subdomain, the service it points to, the team responsible for it, and the date it was created. This makes audits faster and ensures nothing gets forgotten.
• Use automation where possible. If your DNS provider supports it, set up alerts for subdomains that start returning error responses. Infrastructure-as-code tools can also help you manage DNS records declaratively, making additions and removals easier to track.
• Scope your cookies carefully. Avoid setting cookies on your apex domain when they are only needed on a specific subdomain. Tightly scoped cookies limit the damage if an attacker takes over an unrelated subdomain.
• Enforce strong email authentication. Properly configured SPF, DKIM, and DMARC records reduce the risk that a hijacked subdomain can be used for email-based attacks.

Staying on Top of Your DNS

Subdomain takeover is one of those risks that is easy to overlook because it stems from something mundane -- a forgotten DNS record. There is no exploit code involved, no zero-day vulnerability, and no brute-force attack. It is simply a matter of cleanup that did not happen.

The fix is equally straightforward. Audit your DNS records regularly, remove anything you no longer need, and build a process that ensures DNS cleanup is part of every service decommission. A few minutes of maintenance can save you from a serious security incident down the line.

Start by running a DNS lookup on your domain to see exactly what records are in place. If anything looks unfamiliar or points to a service you no longer use, that is your cue to act.