Lapsentry

Orphaned subdomains: what they are and how to find them before someone else does

Updated Oct 2026 · 7 min read

An orphaned subdomain is a subdomain whose DNS record still points to a service, server or IP you no longer use. If someone else can claim that target, they can serve content under your client's domain (subdomain takeover). The fix: inventory subdomains, check every target, delete unused records.

Most agencies manage dozens of client domains, and each of those domains collects subdomains over the years: staging sites, landing pages, help centres, shops, status pages, marketing tools. Services come and go. DNS records tend to stay.

For an agency, the problem is where the risk sits: out of sight. The main site works, the client notices nothing, and the forgotten record often dates from a project or a provider nobody follows anymore. If a stranger uses it, it's the client's name that is exposed, and it's the agency that gets the call to explain what happened.

This guide explains how that happens, how to find orphaned subdomains, and how to stop new ones from appearing. An expired domain is the other way you lose control of a client's name: see what happens when a domain expires.

How does a subdomain become orphaned?

The typical sequence:

  1. 1A subdomain is created for a specific purpose, for example help.example.com for a hosted helpdesk, or promo.example.com for a landing page builder.
  2. 2A DNS record is added, usually a CNAME pointing to the provider (something like example.helpdesk-provider.com).
  3. 3Months or years later, the account at the provider is closed, the trial ends, or the project is abandoned.
  4. 4Nobody removes the DNS record.

The subdomain still exists in DNS, but its target is gone. Sometimes the target hostname no longer resolves at all (an NXDOMAIN response). Sometimes it resolves to the provider's generic "this page doesn't exist" screen.

The same thing happens with A records pointing to IP addresses from a cloud server that was shut down. The IP goes back into the provider's pool and may later be assigned to someone else.

Why does an orphaned subdomain matter?

With many hosted services, you "claim" a custom domain by adding it in your account and pointing a CNAME at the provider. If the original account no longer exists, someone else may be able to create a new account, claim the same subdomain, and serve whatever they want on it.

That is a subdomain takeover. The attacker doesn't need access to your DNS. The dangling record does the work for them.

What can be done with a taken-over subdomain:

  • Phishing pages under a real client domain, which look far more credible than a lookalike domain.
  • Malicious or embarrassing content shown to anyone who visits the old link.
  • Cookie and session risks, if the main site sets cookies scoped to the parent domain.
  • Reputation damage for the client, and awkward questions for the agency that set it up.

Not every dangling record can be exploited. It depends on the provider and on how it verifies domain ownership. But you rarely know which case you're in without checking, and the fix is nearly always the same: remove the record.

Is this a real risk for agencies?

Yes, and the agency carries it even when the domain is in the client's name: when something looks wrong on a client's domain, the client calls the agency that set it up. That is part of who should own a client domain.

This isn't theoretical. In mini-audits we ran on 57 agency sites using only public data, we found a client subdomain with a CNAME pointing to a cloud service target that no longer resolves (NXDOMAIN). It was a single case in that sample. Like most dangling records, it was invisible from the main website and would only show up if someone went looking for it.
Source: Lapsentry mini-audits, 57 agencies, public data only.

How do you find orphaned subdomains?

Build a list of subdomains

You can't check what you don't know exists. Combine several sources:

  • The DNS zone itself. Export it from the registrar or DNS host (Cloudflare, OVH, Gandi, Route 53 and so on). This is the most complete source if you have access.
  • Certificate Transparency logs. Every publicly trusted SSL certificate is logged, the same certificates that fail to renew when a service is abandoned. Searching a domain on a CT log search tool such as crt.sh often reveals subdomains you had forgotten, including ones that only existed for a past project.
  • Email records. Forgotten verification, mta-sts and mail-service records show which providers were once in use; see SPF, DKIM and DMARC.
  • Your own records. Old project docs, handover notes, invoices from SaaS tools that needed a custom domain.

Check where each record points

For every subdomain, look up its records, then check that the target itself still resolves:

dig +short CNAME help.example.com
dig +short A help.example.com
dig +short <target>

Then ask, for each one:

  • Does the CNAME target still resolve? If dig on the target returns nothing or NXDOMAIN, treat it as a red flag.
  • Is the service still in use, and is the account still yours? A target that resolves can still be orphaned if the account behind it is closed.
  • Does the A record IP still belong to a server you control? If the server was decommissioned, the IP may now be someone else's.
  • What does the subdomain show in a browser? Provider error pages like "no such app", "site not found" or "repository not found" are classic signs.

Prioritise

Deal first with:

  • CNAMEs whose target returns NXDOMAIN
  • Subdomains showing a provider's "not found" or "unclaimed" page
  • Subdomains on high-trust domains (main brand, e-commerce, anything handling logins)

How do you fix an orphaned subdomain?

  • If the service is no longer used, delete the DNS record. This is the cleanest fix.
  • If it's still needed, reclaim the custom domain in the provider account and confirm it serves the right content.
  • For A records to retired servers, remove them or point them at infrastructure you control.

How do you stop new orphans from appearing?

Cleaning up once helps. Keeping it clean takes a process:

  • Make DNS part of offboarding. When a client cancels a tool or a project ends, removing the related records goes on the checklist alongside cancelling the subscription.
  • Keep a simple inventory per client: subdomain, what it's for, which provider, who owns the account.
  • Use one DNS host per client where possible, so records don't hide in a forgotten zone.
  • Review subdomains regularly, for example during quarterly maintenance or at every handover.
  • Monitor for change. Records that start returning NXDOMAIN, or new subdomains appearing in certificate logs, are worth an alert rather than an annual discovery.

A quick checklist

  • Export the DNS zone for each client domain
  • Search certificate transparency logs for extra subdomains
  • Check every CNAME target still resolves
  • Confirm every pointed-to service account still exists and is yours
  • Delete records for services no longer in use
  • Add "remove DNS records" to your offboarding checklist
  • Set up ongoing monitoring

How Lapsentry helps

Lapsentry monitors the DNS, SSL certificates and domain expiry dates of the sites you manage, so changes and upcoming problems reach you before your client notices them. If you want to see where your domains stand today, you can start with the free scan, or look at the plans on the pricing page.

FAQ

What is a dangling DNS record?

It is a DNS record, most often a CNAME and sometimes an A record, that still points to a service, server or IP address that is no longer in use. The record stays in your zone, but what it pointed to is gone, so it leads nowhere or to a resource someone else could claim.

Can every orphaned subdomain be taken over?

No. It depends on the provider and on how it verifies who owns a custom domain. Some let anyone claim a name that is not attached to an account, others do not. You rarely know which case you are in without checking, so removing the record remains the fix.

How can I list all subdomains of a domain?

Combine the DNS zone, exported from the registrar or DNS host, with Certificate Transparency logs searched through a tool such as crt.sh. The zone is the most complete source, and the logs reveal subdomains you had forgotten.

Should I delete a DNS record if I'm not sure it's used?

Check first: look in the account of the provider it points to. If the service is no longer used, delete the record. If it is still needed, reclaim the custom domain in that account and confirm it serves the right content.

Building an integration?REST API, webhooks and MCP server are documented separately.Open the docs