Over time, a domain collects records for services you tried and abandoned. A trial of a landing-page builder, a shop on a hosted platform, a status page, a marketing tool someone in the team signed up for in 2021. Each one left a line in your DNS, and nobody removed it when the subscription ended.
If a subdomain such as shop.example.com still points to a hosted service you cancelled, someone else may be able to sign up with that service, claim the name and serve their own content under your domain. This is called a subdomain takeover, and it has been used for phishing and for spreading malware under trusted names.
The cure is dull: review your DNS records twice a year, remove the ones you do not recognise or no longer use, and when you cancel a service, delete its records in the same sitting. The rest of this piece explains why that is worth the effort and how to do the review without breaking anything.
How a takeover works
The usual shape is a CNAME record. Your DNS says that shop.example.com is an alias for a name on the provider's platform, say yourshop.hosting-provider.example. When you cancel, the provider frees that name, but your alias stays. The provider's platform often lets any customer claim any free name, so an attacker registers yourshop and your subdomain now loads their page, with your domain in the address bar and a valid certificate if the platform issues one automatically.
Other records that go stale
CNAMEs are the famous case, but they are not alone. An A record pointing at an address in a cloud range can outlive the server: the address is released, later handed to a stranger, and your subdomain now reaches their machine. An NS delegation to a DNS service you no longer pay for is worse, because whoever claims the zone there controls everything below that name. MX records for a mail provider you left can route messages to a place you no longer own.
Even a TXT record causes trouble. An SPF record that lists include: entries for former services keeps authorising them to send as you. If one of those services reuses its sending addresses or is itself compromised, the permission is still there.
Wider cookie and login risks add to it. A page served from a subdomain can set cookies that apply to the parent domain, and it can look entirely convincing to anyone who trusts your name.
Doing the review
Start with a full list of records. Most control panels can export the zone, and the export is the version worth working from. Do not rely on dig to list a zone, because zone transfers are normally refused.
For each name that is not obviously needed, ask three things: does anyone use it, what does it point at, and does that target still answer? Decide first on paper, then change.
What to look at on your own setup
dig +short CNAME shop.example.com
yourshop.provider.example.
dig +short A yourshop.provider.example
curl -sI https://shop.example.com | head -5Warning signs: the CNAME target returns no address at all (NXDOMAIN), or the page shows the provider's generic "no such site" or "domain not configured" message. Both mean the pointer is dangling. Compare it against what you pay for. The troubleshooting guide has more on reading DNS output.
Keep a note of the cause for each deletion. Six months later someone will ask why status.example.com vanished.
Teams change, and the person who set up a record may have left. If nobody can say what a name is for, treat it as unowned: put a date on the question, and delete it if no one answers.
Habits that prevent it
- Delete the DNS record before or at the same time as cancelling the service. Order matters: remove the record first, then cancel.
- Lower the TTL a day before any change, so a mistake is quick to reverse (the TTL planner helps).
- Name records after the service and date in a comment field if the DNS host has one.
- Put a recurring calendar item in spring and autumn.
Things people ask
Will deleting a record break something?
Occasionally. If you are unsure, lower the TTL, delete, and watch for complaints for a day. Restoring a record is quick.
Does my host monitor for this?
Few do. Some platforms now require you to prove ownership before a name can be claimed, which closes part of the hole, but many do not.
Is a wildcard record a risk?
A wildcard CNAME to a third party makes every unused name under it claimable. Use them with care.