In this guide · 7 sections
Short answer
A dangling DNS record points a subdomain at a cloud service you no longer use. If someone else can claim that service name, they control content on your subdomain. Fix it by removing DNS records first when you shut a service down, and by reviewing all records every quarter.
How a subdomain takeover happens
Microsoft's guide to preventing dangling DNS entries describes the usual sequence. A business creates a cloud resource, points a subdomain to it with a CNAME record, and later deletes the resource. The CNAME stays. The subdomain is still advertised as active but leads nowhere, and someone else can create a resource with the same name on the same platform and receive its traffic.
A service is set up
For example, promo.yourcompany.com is pointed with a CNAME to a hosted app, storage bucket or landing page builder.
The service is cancelled
The campaign ends or the trial lapses, and the app or bucket is deleted. Nobody tells whoever manages DNS.
The record is left dangling
promo.yourcompany.com still points to the old platform address, which now shows an error.
An attacker finds it
Scanning tools check public DNS and certificate logs for subdomains that point to unclaimed resources.
The attacker claims the name
They create a new resource with the same name on that platform. Your subdomain now shows their content, with a valid HTTPS certificate.
MDN's subdomain takeover page notes the same risk at set-up time: if you add the DNS record before claiming the service, someone faster can claim it first.
Why it matters for a small business
A taken-over subdomain looks like part of your business because it is part of your domain. Microsoft's guidance lists the main consequences:
- Phishing: a login or invoice page on yourcompany.com is far more convincing than a lookalike domain.
- Cookie theft: web apps that share session cookies across subdomains can expose them to a page the attacker controls.
- Email: dangling MX records can let someone receive email sent to a subdomain.
- Reputation: search engines and customers see whatever content the attacker publishes under your name.
Lookalike domains are a related but different threat; our guide to lookalike domain impersonation and takedowns covers those.
Which records and services are most at risk
Any record that points to a shared platform where names are first-come, first-served can dangle. The risk depends on whether the platform checks that you own the domain before connecting it.
| Record type | Typical target | Why it can dangle |
|---|---|---|
| CNAME | Cloud app hosting, storage buckets, landing page builders, help desks, GitHub Pages | Service deleted or plan downgraded, record left in place |
| A record | An IP address from a cloud provider | Server deleted; the IP can be reassigned to another customer |
| MX | Old email service or marketing platform | Account closed, mail routing still points there |
| NS | A subdomain delegated to another DNS host | Zone deleted at the other host and claimable by someone else |
Some platforms now add protection. GitHub's domain verification for Pages stops other users publishing to your verified domain and its immediate subdomains, and GitHub says takeovers can follow a deleted repository or a downgraded plan. Azure offers alias records and dangling DNS alerts in Defender for App Service. Where a platform offers verification, use it.
How to find dangling DNS records
You need a full list of your DNS records and a check of where each one points. For most small businesses this is an hour's work.
Export the zone
Most DNS hosts let you export all records. Cloudflare's import and export guide explains how to download a zone file.
Find subdomains you forgot about
Search certificate transparency logs (for example crt.sh) for your domain. Certificates issued for old subdomains show names you may no longer have in mind.
Check each CNAME target
Open each subdomain in a browser. Platform error pages such as 'no such app', 'NoSuchBucket' or 'there isn't a GitHub Pages site here' are warning signs.
Match each record to an owner
Write down who uses each record and which account the service sits in. Records nobody can explain are candidates for removal.
Remove or fix
Delete records for retired services. If a record is still needed, point it at a resource you control and verify the domain on that platform.
If you find a subdomain already showing someone else's content, MDN's advice is to remove the DNS entry first, then investigate as an incident: check whether users visited it, whether cookies or credentials could have been exposed, and report it to the platform.
A quarterly DNS review routine
The fix is a habit rather than a tool. MDN recommends a simple order: when launching, claim the service first and add DNS last; when retiring, remove DNS first. Add a short review every quarter.
Quarterly DNS review
Cyber Essentials expects an up-to-date asset inventory; your DNS register fits naturally into it. See our Cyber Essentials mark checklist, and our explainer on nameservers vs DNS records if the terms are new.
Do it yourself or get help?
With access to your DNS host and an hour, you can do the export, the browser check and the cleanup yourself. The harder part is knowing what each old record was for, especially when past agencies set them up.
Our Domain & DNS Setup (S$99) puts your domain in your name and sets clean records for website and email. For a wider look, the Security Health Check (S$290) reviews your domain, website, email and Microsoft 365 or Google Workspace settings and gives a ranked fix list. IT Sorted is a Singapore-based team of developers with over 10 years of experience; you pay upfront, send the brief in writing and follow progress on your order page.
Frequently asked questions
It is a DNS record, usually a CNAME, that still points a subdomain to a cloud service or server that has been deleted. The subdomain appears active but leads nowhere. On platforms where names are first-come, first-served, someone else can create a resource with that name and take over your subdomain.
Visit each subdomain you have and look for content you did not publish, or for platform error pages such as 'no such app' that show it is claimable. Certificate transparency logs may also show certificates issued for your subdomains that you did not request. If content is not yours, delete the DNS record immediately.
Yes, indirectly. The attacker can host a convincing login page on your real domain for phishing. If your web apps share session cookies across subdomains, a page on the taken-over subdomain may also be able to read them. Treat any confirmed takeover as a security incident.
Yes, and before you delete the service if possible. Removing the DNS record first means there is never a moment when your subdomain points at a name someone else could claim. Add this to your offboarding checklist for vendors, agencies and trials.
Quarterly is a sensible rhythm for a small business, plus a check whenever a vendor, agency or campaign ends. Export the zone, confirm each record has an owner and points to something you still control, and delete what is no longer needed.