Domain security
Subdomain takeover: how to prevent it
How a forgotten DNS record hands a trusted subdomain to someone else, why your suppliers' DNS matters too, and the checks that close the gap.
Key takeaways
- A dangling DNS record points to a resource you no longer hold.
- Whoever claims that resource controls content on your subdomain.
- The attacker can obtain a valid certificate, so the padlock proves little.
- Make DNS removal a required step when you retire a service.
- Supplier subdomains you trust carry the same risk, but they must fix it.
Subdomain takeover happens when a DNS record, usually a CNAME, still points to a cloud resource you deleted, and someone else claims that resource and controls what the subdomain serves. Prevent it by removing DNS records before or when you retire resources, verifying custom domains with your providers and reviewing your own and key suppliers' DNS regularly.
What is a subdomain takeover?
Every organization depends on suppliers, agencies and cloud services, and many of those relationships leave DNS records behind. When a subdomain still points to a resource that no longer exists, someone else may be able to claim that resource and serve their own content under a name your staff and customers trust.
Definition
A subdomain takeover is when someone other than the domain owner gains control of the content served on a subdomain, usually because a DNS record still points to a third-party resource that was deleted and has since been claimed by someone else.
Microsoft describes the root cause as a DNS record "that points to a deprovisioned Azure resource," known as a dangling DNS entry, and notes that CNAME records are especially vulnerable.[1] OWASP's testing guide adds that the issue can affect A, CNAME, MX, NS and TXT records.[2] An NS takeover is less likely, but OWASP says it "has the highest impact," because it can mean "full control over the whole DNS zone."[2]
In a supply chain setting, the vulnerable subdomain belongs to someone you trust: an agency hosting a campaign site, a SaaS provider's customer portal, a logistics partner's tracking page or a subsidiary's old microsite.
How does a takeover happen?
Microsoft's documentation walks through the common pattern in three stages:[1]
- Creation. A team provisions a cloud resource and adds a CNAME so a friendly subdomain points to it.
- Deprovisioning. The resource is deleted when no longer needed, but the CNAME stays in the DNS zone.
- Takeover. Someone finds the dangling record and provisions a resource with the same name, so traffic to the subdomain reaches content they control.
The gap is a process gap, not a software bug. The resource and the DNS record live in different systems, often managed by different teams.
Why does it matter for your brand?
Microsoft lists the consequences: loss of control over the subdomain's content and the brand damage that follows, phishing from authentic-looking addresses, and cookie harvesting, because web apps often share session cookies across subdomains.[1] It also corrects a common assumption: an attacker can use the hijacked subdomain to obtain a valid TLS certificate, so the padlock in the browser proves nothing about who runs the page.[1]
MX records add an email angle. Microsoft notes they "could enable threat actors to receive emails directed to legitimate subdomains associated with trusted brands."[1]
Which of your subdomains point nowhere?
A free growth diagnostic checks your email authentication (SPF, DKIM, DMARC), lookalike domains, domain renewals and ownership, and obvious fake profiles or pages, and names what needs a specialist firm. Your top 3 findings and a 30-day fix plan in writing within 2 business days.
Why is it a supply chain risk?
- Indirect ownership. You cannot fix a supplier's dangling record. You can only detect it, tell them and limit your own exposure.
- Lower scrutiny. Email filters, web proxies and staff often treat known partner domains as safe, so a hijacked partner subdomain can get through.
- Shared blame. If your customers are phished through a supplier's subdomain that carries your campaign, they are likely to hold you responsible.
- Hard to inventory. Campaign sites, test environments and integrations are easy to forget once a project or contract ends.
What could a takeover look like?
Illustrative sample
A hypothetical manufacturer's agency built a product launch microsite on a cloud host under a subdomain of the manufacturer's domain. After the campaign, the agency deleted the hosting resource but nobody removed the CNAME. A periodic DNS review by the manufacturer flags the record as pointing to a resource that no longer exists, and the record is deleted before anyone else claims it.
How do you protect your own domains?
- Remove DNS records as part of decommissioning. Microsoft recommends putting "Remove DNS entry" on the list of required checks when a service is retired, and using delete locks on resources with custom DNS entries as a reminder.[1]
- Review records regularly. Check that each subdomain points to a resource that exists and that you own, and keep a catalog of endpoints and their owners.[1] OWASP recommends continuous monitoring and periodic checks.[2]
- Use provider safeguards. Azure DNS alias records tie a record's lifecycle to the resource, and App Service domain verification TXT records stop other subscriptions from validating your custom domain.[1] GitHub says verifying a custom domain "stops other GitHub users from taking over your custom domain."[3]
- Avoid wildcard DNS records. GitHub strongly recommends against records such as
*.example.com, which it says put you at "immediate risk of domain takeovers, even if you verify the domain."[3] - Tie DNS to infrastructure code. Where you can, create and delete records in the same change as the resource they point to.
How do you manage the risk with suppliers?
- Ask about DNS hygiene in vendor reviews. Ask how suppliers retire subdomains and who owns their DNS.
- Watch the subdomains you rely on. Keep a list of supplier subdomains your staff and customers use, and review them for records that point to missing resources.
- Limit implicit trust. Do not exempt partner domains from email and web filtering just because they are familiar.
- Write it into contracts. Agree that suppliers maintain their DNS and notify you of security issues on subdomains that serve your users.
What should you do if you find one?
- Remove or block. If the record is yours, delete it or point it to a resource you control.[1] If it is a supplier's, block the subdomain in your email and web filters while they fix it.
- Tell the owner. Send the supplier's security contact the record and what it points to. Their security.txt file, if they publish one, lists that contact.
- Check for impact. Microsoft recommends investigating whether any compromise occurred, including whether secrets or personal data were sent to the subdomain.[1] Incident response is work for your security team or a specialist firm you contract with.
- Fix the process. Find out why the record was left behind so it does not happen again.[1]
Subdomain takeover sits alongside the other basics of corporate DNS security, registry locks and a domain portfolio audit. Our domain security service covers DNS records, renewals and ownership as part of our digital asset security work.
Sources
Written under our Editorial and AI Policy. Sources checked 19 Oct 2026. Reviewed by DGo Digital on 19 Oct 2026.
FAQ
Questions about subdomain takeover
A dangling DNS record is an entry in your DNS zone that still points to a resource, such as a cloud app or storage endpoint, that has been deleted. The name still resolves as if it were in use. If someone else can create a resource with the same name, they can serve content on your subdomain.