Dangling DNS: Subdomain Takeover and Email Impersonation Risks

A company may stop using a service but forget to remove its associated DNS record. This might not seem like a big issue, but it can leave a gap that attackers can take advantage of. Attackers may use these records to take over subdomains that still appear to belong to the company.

This can cause problems beyond the website itself. For example, attackers could use a taken-over subdomain to host fake login pages or make phishing emails look more trustworthy. The actual risk depends on the DNS setup and whether the attacker can claim the resource linked to the record.

In this blog, we’ll explain how dangling DNS can lead to subdomain takeover, how it can affect email security, and what you can do to find and fix these issues before attackers get to them.

What Is Dangling DNS and How Does It Create Security Risks?

Dangling DNS happens when a DNS record points to a service or resource that a company no longer uses or controls. This often happens when a company moves to a new hosting provider, cancels a SaaS subscription, or deletes a cloud resource but forgets to update its DNS records.

For example, a company may stop using a third-party platform but leave its CNAME record in place. The record still points to the old service, even though the company has stopped using it. These dangling DNS records can go unnoticed for months, especially when different teams manage cloud services and DNS settings.

Not every old DNS record is a security issue. Some may simply point to a service that is no longer available. The real concern is whether someone else can claim the resource linked to the record. If they can, the company may lose control over that subdomain without making any changes to its own DNS settings.

How Do Dangling DNS Records Become a Security Risk?

The risk depends on the service behind the DNS record and whether its provider allows another user to claim the abandoned resource. If the resource is available, an attacker may be able to set it up under their own account while the company’s DNS record still points to it.

This can lead to a subdomain takeover, where an attacker gains control over content served through a subdomain that belongs to the company. They could use it to host fake login pages, redirect visitors to malicious websites, or run phishing campaigns that appear connected to the organization.

For example, suppose support.example.com points to a third-party hosting service. After the company closes its account, an attacker claims the released resource and uploads a fake customer support page. Visitors who trust the company’s domain may enter their login credentials without realizing the page is controlled by an attacker.

The impact can go beyond website abuse, too. If the affected subdomain is used in email campaigns or links included in company emails, attackers may exploit that existing trust to make phishing messages more convincing.

How Does a Dangling DNS Attack Lead to Subdomain Takeover?

Attackers can use automated tools to find subdomains that point to resources that may no longer exist. They check DNS records, look for failed connections, and compare the results with error messages from cloud providers and hosting platforms. These errors can help them find possible targets, but they still need to check whether the resource can actually be claimed.

So, how do attackers find and claim abandoned resources?

Well, the process usually involves three steps:

1. Find vulnerable DNS records: Attackers collect subdomains and check their DNS records for links to third-party services. CNAME records are often worth checking because they point to another hostname, such as a cloud hosting service or CDN endpoint.

2. Check the linked service: Then cyberactors visit the target or check its response for signs that the resource is missing or no longer assigned. For example, a hosting platform might show an error saying that the requested site or application cannot be found. This alone doesn’t prove a vulnerability, but it can help identify a resource that needs further testing.

3. Try to claim the resource: If the provider has released the resource and allows someone else to register it, an attacker may create a new resource with the required name or identifier. The old DNS record can then direct visitors to the attacker’s resource without any changes to the company’s DNS settings.

Which Services Can Be Affected?

The risk depends on the service the DNS record points to:

Cloud Hosting Platforms

Companies use cloud platforms to run their websites, applications, and APIs. Sometimes, they delete a cloud resource but forget to remove the DNS record pointing to it. If the provider allows someone else to claim that resource, an attacker may be able to put their own content on the subdomain that the company still has in its DNS.

Content Delivery Networks (CDNs)

CDNs help deliver website files, images, scripts, and other content to users. A company may stop using a CDN service but leave its custom hostname linked to the old configuration. If that configuration is no longer assigned to the company and the provider allows it to be claimed, an attacker may be able to serve their own content through that hostname.

SaaS Platforms

Companies often connect their domains to SaaS tools for help centers, customer portals, landing pages, and marketing campaigns. When they stop using one of these tools, they may forget to remove the related DNS record. If another user can claim the abandoned resource, they may be able to control the content available through that subdomain.

Not every provider allows someone else to claim an abandoned resource. Some also have checks in place to stop this from happening. So, security teams need to check whether a resource is actually vulnerable before treating a dangling DNS record as a confirmed risk.

A successful dangling DNS attack can give an attacker control over a subdomain without giving them access to the company’s DNS account. Regular dangling DNS detection helps security teams find these records, check whether the linked resources can be claimed, and remove or fix vulnerable entries before attackers can use them.

How Dangling DNS Records Increase Email Impersonation Risks

A subdomain takeover can also create problems for email security, especially when the affected subdomain is used in email campaigns, tracking links, or other customer-facing services. Attackers may use this access to make phishing attempts look like they come from a company that people already know and trust.

Here are a few ways attackers can misuse these subdomains:

Phishing Links

Attackers may use a compromised subdomain in phishing emails to make their messages look like they come from a trusted company. For example, they could include a link to a fake login page under a subdomain that customers have seen in earlier emails. Since the address looks familiar, recipients may not question it and could end up sharing their passwords or other sensitive details.

Email Tracking and Landing Pages

Companies often use subdomains to track email clicks or send users to campaign landing pages. If attackers take control of one of these subdomains, they may be able to change the content or redirect visitors to another website. This can affect people who click links in older emails, too. Even a campaign sent months ago could become a risk if its links still point to the compromised subdomain.

Abandoned Email Services

Some subdomains are connected to third-party services used for email delivery or other email-related tasks. If a company stops using a service but its DNS records remain, an attacker may be able to claim the released resource, depending on the provider’s rules. In some cases, this could let them misuse parts of the email setup. The actual impact depends on the DNS record type and how the service handles domain ownership.

How to Detect Dangling DNS Entries Before Attackers Exploit Them

Finding dangling DNS entries can be tricky, especially when a company has hundreds of subdomains connected to different services. Security teams need to know which DNS records are still needed and which ones point to resources that are no longer in use.

Check CNAME Records

Start by reviewing CNAME records that point to third-party services. These records can become a problem when the linked resource is deleted or no longer assigned to the company. Look for hostnames that return errors or point to services that are no longer active. However, an error alone does not confirm that a record is vulnerable.

Compare DNS Records With Active Resources

Check the DNS inventory against the company’s current cloud resources, hosting accounts, CDNs, and SaaS subscriptions. For example, if a DNS record points to a hosting service that no team uses anymore, investigate whether the resource still exists and who controls it. This comparison helps teams find old entries that may have been missed during service changes.

Look for Provider-Specific Errors

Some cloud and hosting providers show specific error messages when a resource is missing or no longer assigned. These messages can help identify possible dangling DNS entries. But don’t assume every error means an attacker can claim the resource. The provider’s resource allocation rules and ownership checks also need to be considered.

Scan Subdomains Regularly

Run regular scans to check existing subdomains and identify changes in their DNS responses. Pay attention to records linked to inactive services, unexpected changes, and hostnames that suddenly stop resolving. Automated dangling DNS detection tools can help with these checks, especially when the organization manages a large number of domains.

Validate Findings Before Taking Action

Once a suspicious record is found, confirm that the linked resource is actually unassigned and could be claimed by someone else. Temporary service outages, configuration mistakes, and provider issues can also cause errors. Removing records without checking their purpose may disrupt active websites or business services.

DNS monitoring and asset inventory tools can help security teams keep track of these changes. When used together, they make it easier to find exposed entries and investigate them before attackers can take advantage of them.

How to Prevent Dangling DNS Attacks and Reduce Email Spoofing Risks

Finding dangling DNS records is only one part of protecting a domain. Companies also need to ensure their DNS resources are managed properly and that abandoned services don’t leave security gaps.

Remove DNS Records When Services Are No Longer Needed

When a company stops using a cloud service, hosting platform, or SaaS tool, it should remove the related DNS records. Keeping unnecessary records can create opportunities for attackers if the linked resources become available for someone else to claim. Removing these entries also helps keep the company’s DNS setup clean and easier to manage.

Include DNS Cleanup in the Decommissioning Process

Deleting a cloud resource or closing a SaaS account should not be the final step when retiring a service. DNS cleanup should be part of the same process. Teams responsible for DNS should be informed whenever a service is discontinued so they can remove related records along with the resource.

Manage Third-Party Services and Subdomain Access

Companies should keep track of the third-party services connected to their domains. This includes knowing which team owns each service and who is responsible for its maintenance. Access to DNS management accounts should also be limited to authorized personnel. This reduces the chances of accidental changes or unauthorized modifications to DNS records.

Strengthen Email Authentication

Dangling DNS can also enable email impersonation. Companies should configure SPF, DKIM, and DMARC for their sending domains and relevant subdomains.

EasyDMARC’s SPF Lookup, DKIM Lookup, and DMARC Lookup tools can help check published records and identify configuration issues. These checks help teams understand whether their email authentication is set up correctly. However, email authentication does not prevent subdomain takeover itself.

Make DNS Security Reviews a Regular Task

DNS security should be part of routine attack surface management, not something teams check only after an incident. Regular reviews, clear ownership, and proper service retirement processes can help companies reduce dangling DNS risks and limit opportunities for subdomain abuse.

Building a More Resilient DNS Security Strategy

As companies continue to adopt cloud services, SaaS platforms, and new digital tools, their DNS environments will keep changing. Managing these changes will become an important part of keeping their domains secure.

Security teams will need to look beyond traditional security controls and pay closer attention to how domain assets are created, used, and retired. Making DNS ownership part of everyday security planning can help organizations stay prepared for new attack methods.

As the threat landscape continues to evolve, organizations that treat DNS security as an ongoing responsibility will be better positioned to protect their domains, customers, and digital reputation.

Frequently Asked Questions

Can Dangling DNS Records Affect a Company’s SEO?

Yes. If attackers take over a subdomain that search engines have indexed, they may publish spam or harmful content under it. This can affect the company’s reputation and how search engines view the affected pages.

Can a Dangling DNS Record Affect an SSL/TLS Certificate?

It can. If an attacker takes control of a subdomain, they may be able to obtain a certificate for it through certificate authorities that allow domain validation. This can make a malicious website appear to have a valid HTTPS connection.

Are Wildcard DNS Records Vulnerable to Subdomain Takeover?

Wildcard DNS records do not automatically create a subdomain takeover risk. However, if a wildcard record directs requests to a third-party resource that can be claimed by someone else, it may increase the number of subdomains exposed to potential abuse.

Can Dangling DNS Records Be Exploited Even If a Company Uses a Web Application Firewall (WAF)?

Yes. A WAF mainly protects web applications by filtering incoming traffic. It does not prevent an attacker from claiming an abandoned third-party resource linked to a DNS record. The takeover risk needs to be addressed at the DNS and resource management level.