Map the dependency before naming the risk
A stale DNS reference can leave a subdomain pointing at a service the organization no longer controls. Whether another party can claim that service depends on the provider's allocation and domain-verification rules. Even when a takeover exposure exists, the resulting authority is not automatically control of all email for the parent organization. A useful investigation maps the exact record, the external dependency and the trust relationships that consume it before deciding what the exposure could enable.
Microsoft's Azure subdomain-takeover guidance describes dangling DNS references, provider-specific protections and cleanup. It supports investigating stale dependencies, not assuming that every unresolved CNAME is exploitable. This article proposes defensive review and change planning only. No third-party resource was registered, no name was claimed, no DNS record changed and no test message sent.
Distinguish references, delegation and actual control
RFC 1035 defines CNAME and NS record formats. A CNAME points a particular DNS name toward another name; it is not by itself delegation of an entire zone. A child-zone delegation has a different scope because the delegated servers can answer for names within that zone. A stale web-hosting reference, a delegated marketing subdomain and a DKIM selector pointing to a supplier therefore require different dependency maps. Treating them all as “the domain was taken over” discards the information needed for remediation.
List the exact owner name, type, value, zone and authoritative operator. Record the service account or supplier expected to control the target and the evidence for that relationship. An unavailable target is an observation about resolution or service state, not proof that it is available for another customer to claim. Provider reservations, verification tokens and lifecycle restrictions can change that conclusion. Check current documentation and authorized ownership records without attempting a resource claim to demonstrate risk.
Separate web control from email authority
Control of a web endpoint can affect content served at that name and any application that trusts it. It does not necessarily allow changing the parent domain's SPF, publishing arbitrary DKIM keys or operating its mailboxes. Conversely, control of an email-relevant delegated zone or selector target can have a different security impact. The investigation must identify which DNS names the email mechanism actually consults and who can alter their responses.
RFC 6376 describes DKIM key retrieval using the selector and signing domain. A stale selector dependency is therefore not equivalent to a stale unrelated website CNAME. Potential signing implications depend on the key material, the lookup path and the ability to produce a valid signature; they should not be asserted merely from a broken web page. No private key or signing test is needed for the documentary dependency review proposed here.
Evaluate alignment and inherited assumptions carefully
RFC 9989 defines alignment and policy discovery for DMARC. Related domains may interact differently under relaxed or strict alignment, so the visible From domain and authenticated domain must be recorded exactly. Do not assume every subdomain is isolated from every parent identity, or that one subdomain's control automatically authenticates arbitrary parent-domain mail. The actual mechanism and policy determine the relationship.
There may also be application trust outside the authentication protocols. An internal allowlist, brand association, callback URL or user expectation could treat a subdomain as trusted. Document each such relationship as an application or business dependency rather than a DNS standard rule. Microsoft warns that secrets or sensitive information sent to dangling subdomains can be exposed. This is a reason to review dependent applications, not a claim that any such exposure happened in the organization under review.
Apply provider protections within their documented scope
Azure's guidance describes App Service custom-domain verification using an asuid TXT record and a domain verification ID. It also explains that preventing another subscription from validating the custom domain is distinct from preventing creation of an App Service instance with a matching service name. These are provider-specific protections. They do not establish that every Azure service, every DNS record or another cloud provider uses the same lifecycle rules.
The same guidance describes Azure DNS alias records coupling certain supported resource lifecycles to DNS references, with limits on supported targets. Do not generalize that behavior to ordinary CNAME records or all providers. For each dependency, record the applicable protection, where its current evidence is retained and what remains unverified. A documented protection can reduce a particular exposure without proving that all application or email trust relationships are safe.
An exact-record change worksheet
Prepare an approved change plan with the current complete record set, intended diff, target dependency, business owner, active consumers and restore material. Include the reason for retirement or correction, current provider constraints, verification plan and rollback decision criteria. A deletion is not automatically safe merely because a service appears unused; queued mail, active selectors, customer workflows or a replacement service may still depend on the name.
Keep the dependency map separate from the authorization record. A researcher can identify a possible stale reference without being authorized to remove it. After an approved change, the operational team would retain authoritative and recursive lookup evidence with times, names and record types. Cached answers and provider state can outlast a change, so deletion alone is not proof of immediate universal revocation. No such diff, lookup or rollback was executed for this manuscript.
Fictional diagnosis: a retired campaign service
A fictional organization retires a campaign platform but leaves two DNS references: a website CNAME and a DKIM selector CNAME. An inventory tool reports that the website target is unavailable. The team initially assumes both records create identical takeover risk. The proposed review instead maps the targets, provider account ownership, custom-domain verification rules and email-signing dependencies separately. The unavailable website result does not establish the selector's state or another party's ability to claim either resource.
The mail owner would check whether the selector still supports active or queued signing workflows before proposing retirement. The web owner would review the campaign endpoint and any application trust attached to it. Both proposed changes would require exact restore material and approved verification. This is a fictional lifecycle exercise, not a discovered dangling record, resource claim, successful takeover or completed offboarding. No real service identifier or credential was collected.
Close the control boundary with evidence
A defensible report names the stale dependency, its verified control state, the mechanism through which trust could be affected and the approved corrective action. It distinguishes potential exposure from confirmed exploitation. It also records residual uncertainties, such as incomplete supplier ownership evidence or unobserved cache behavior. Avoid describing a provider-specific protection as a universal guarantee or a deleted record as proof that historical misuse never occurred.
The catalogue requires an approved exact-record diff, dependency map, restore material and post-change lookup evidence. Those original artifacts remain open. The proposed worksheet does not satisfy them, and all other release gates remain open. Human specialist review, source applicability, production routes, accessibility and owner approval must be completed before publication. The purpose is to make cleanup safer and more precise without performing a takeover demonstration or overstating inherited email authority.