Subdomain takeover is an ops problem too

Subdomain takeover is usually written up as a security exploit to hunt for, but for most teams it starts as an ops mistake: a CNAME left behind when a SaaS integration, staging environment, or acquired subdomain gets decommissioned, and nobody deletes the record.

What a dangling CNAME actually is

A CNAME record points your subdomain at a resource hosted somewhere else: an S3 bucket, a Heroku app, a GitHub Pages site, an Azure endpoint, a help-desk tool's custom domain. That resource eventually gets deleted, deprovisioned, or the account gets closed, but the CNAME record itself keeps pointing at the same name. DNS still resolves correctly, your subdomain still points where the record says it does; the problem is that the provider no longer has anyone assigned to that name, so anyone who notices can register the same resource name at the provider and start receiving traffic for your subdomain, cookies included.

Nothing about DNS is broken here. The record is doing exactly what it was configured to do. The failure happened one step earlier, when whoever decommissioned the underlying resource did not also remove the record pointing at it.

A quick manual check confirms whether a given CNAME is actually dangling: resolve it and look at what the target returns. An S3 bucket that no longer exists answers with a distinct NoSuchBucket error, an unclaimed Heroku app returns its own "no such app" page, and a removed GitHub Pages site serves a recognizable 404. Each provider has a different tell, but the pattern is the same: a normal, healthy response looks nothing like these, so a CNAME that resolves to one of them is worth investigating regardless of how it got there.

The security framing misses who actually creates this

Search for how to prevent subdomain takeover and the results are consistently written for a security team: attack-surface management platforms, penetration-testing checklists, threat-actor writeups. One widely-cited 2026 guide goes as far as arguing that routine DNS monitoring is not enough on its own, that dangling records need dedicated exposure-management tooling to catch reliably.

That is not wrong for a security team's threat model. But it skips who actually creates the exposure in the first place, and it is rarely an attacker. It is whoever ran the vendor offboarding, closed the cloud account, or wound down the campaign microsite, doing routine ops work with no reason to think of it as a security task.

Three ordinary events that leave the door open

• SaaS decommissioning: a help-desk tool, a marketing landing-page builder, or a status-page vendor gets replaced. The subdomain that pointed at it, help.yourcompany.com or status.yourcompany.com, never comes off the list to update.
• Vendor or cloud migration: an S3 bucket gets renamed or moved to a different account during a platform migration, and the CNAME that pointed at the old bucket name is left in place because the migration checklist covered the new setup, not the old one.
• Campaign or M&A subdomain sprawl: a promo microsite, an acquired company's old subdomain, or a short-lived staging environment gets spun up for a project, the project ends, and the DNS record is the only remaining evidence it ever existed.

None of these involve anyone doing anything wrong on purpose. They are what normal infrastructure lifecycle looks like at any company that has been running for more than a year or two.

What DNS monitoring gives you, and what it does not

WebPixie's DNS monitoring checks CNAME records daily, alongside 20+ other record types, and flags any change with the old and new value side by side. That gives you visibility into every CNAME your domain currently has and when one last changed, which is the same data a record-change detection workflow is built on. It is a real, useful piece of the picture: you cannot clean up a dangling record you do not know exists.

It is not, on its own, a takeover-risk verdict. Seeing that help.yourcompany.com still points at a provider does not tell you whether that provider account is still active, still yours, or sitting unclaimed and ready for someone else to register. That check happens at the provider, not in DNS, and it is a manual step (or a dedicated exposure-scanning tool, per the security-side guides) layered on top of the visibility monitoring gives you.

Making DNS cleanup part of decommissioning, not an afterthought

The fix is not more scanning, it is treating every "we are done with this vendor" moment as a DNS cleanup trigger, the same way removing a departing employee's access is a standard offboarding step. When a SaaS tool gets replaced, a cloud resource gets renamed, or a campaign wraps up, deleting the associated DNS record belongs on that checklist, not on a separate security review that may never happen.

For records that predate that discipline, which is most companies' actual starting point, the practical move is a one-time pass through your current CNAMEs asking which provider each one still legitimately belongs to, using exactly the kind of daily-refreshed record list DNS monitoring already gives you. After that, the discipline is what keeps the list from drifting again.