[ Spoofing & identity abuse ]

Subdomain abuse through neglected third-party dependencies

Find stale domain delegations without confusing a missing resource with a proven email takeover.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Find stale domain delegations without confusing a missing resource with a proven email takeover.
  • A missing web resource does not by itself prove claimability or email-sending authority.
On this page

An abandoned service can leave an active relationship to your domain long after the business stops using it. Review that relationship as an ownership problem: identify the DNS name, the resource it points to, who can bind that resource and what mail capability the dependency actually grants. A stale web alias is not automatically an ability to send aligned email.

Trace the complete dependency

Start with an authorized inventory export, not a scan for resources you could claim. Record the DNS owner name, record type, target, service account, business owner and last verified use. Microsoft describes how dangling DNS entries can create subdomain-takeover risk when referenced resources disappear. Its Azure-specific prevention mechanisms should not be assumed to exist at another vendor. Microsoft guidance.

Separate CNAME hosting, delegated DNS zones, DKIM selector delegation and SPF authorization. These relationships grant different capabilities. A service hosting a page at news.brand.test does not necessarily possess a signing key for brand.test. Conversely, an obsolete selector delegation can leave an authentication dependency even when no visible website remains. Inventory the effective authority rather than grouping everything as a domain takeover.

Establish the mail boundary

DMARC evaluates authenticated identifiers in relation to the message's author domain. A policy result does not establish whether the organization still intends a third party to have that authority. RFC 9989. Preserve the exact From, envelope and signing domains from an authorized sample if mail is involved. Use trusted receiver evidence, and distinguish a valid signature from an approved business sender.

A missing resource is an investigation lead. Claimability may depend on provider verification, retained reservations and account state. Do not claim an external resource to prove the point without explicit authorization. Ask the accountable service owner to confirm retirement and consult current provider guidance. Uncertainty belongs in the record, not in an accusation that a takeover has happened.

Work through a written dependency ledger

Assume three CNAME rows in a hypothetical authorized inventory. The targets are reserved example names, not live provider resources.

  • news.brand.test points to retired-service.example.test. Resource retirement and marketing-owner confirmation are stipulated. Propose removal only after checking other dependencies and obtaining actual change approval; claimability and mail authority remain untested.
  • alerts.brand.test points to active-service.example.test. Resource and operational owner are assumed active. Retain the mapping and verify its intended use; activity does not by itself prove safe isolation or domain ownership.
  • unknown.brand.test points to uncertain-service.example.test. Resource status and owner are unknown. Assign investigation, not a compromise finding or a safe-to-delete conclusion.

No code reconciled these rows, no public DNS was queried and no resource was claimed. The written next actions depend on stipulated facts. Replace them with dated inventory and owner evidence in a real change. Keep CNAME hosting, SPF authority and DKIM delegation as separate inventory types rather than deriving mail capability from a web alias.

Retire dependencies in a controlled order

Agree the retirement sequence with the DNS and service teams. Confirm that the mapping no longer supports mail, websites, verification challenges or another live dependency. Remove or change the domain relationship through the approved change process, then verify the authoritative DNS and any affected message routes. Preserve a recovery plan for an accidental removal, while avoiding an indefinite stale delegation as the rollback strategy.

Close the case with the observed relationship, ownership confirmation, exact approved change and verification time. Keep unresolved provider behavior explicit. A recurring reconciliation between DNS records and the service inventory is more useful than a one-time list of alarming names. The objective is to remove unnecessary authority without interrupting a legitimate route.

[ Takeaway ]

A missing web resource does not by itself prove claimability or email-sending authority.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Map the actual authority

DNS relationships have different effects.

Next steps

  1. Inventory exact record names.
  2. Check signing and SPF dependencies.
  3. Verify approved changes.

CISO / SecOps

Avoid unsupported takeover claims

Evidence must establish capability.

Next steps

  1. Preserve unknown states.
  2. Require authorization for active testing.
  3. Review residual access.

Founder / Non-technical

Fund dependency ownership

Retirement requires a named decision maker.

Next steps

  1. Name the service owner.
  2. Confirm business retirement.
  3. Approve continuity requirements.

[ FAQs ]

Frequently asked questions

Does a dangling web alias prove email takeover?

No. Establish which DNS, signing or sending authority the dependency actually grants.

Can a missing resource be safely called exploitable?

Not without provider-specific evidence of claimability and control.

Should I claim a resource to demonstrate the risk?

Only under explicit authorization; this workflow uses non-destructive inventory reconciliation.

Why include the business owner?

The owner can distinguish retired services from low-volume but legitimate dependencies.

Can DMARC pass for an unwanted old service?

Yes, if the service still has a valid aligned authentication route.

What should remain unknown?

Unverified resource existence, ownership, claimability and email authority.

What was tested in this example?

Nothing operational. The three written rows illustrate proposed inventory decisions, not DNS checks, code execution or service takeover.

When is retirement complete?

After approved dependency removal and verification of DNS and affected legitimate routes.

[ Sources ]

Sources

  1. Microsoft prevent dangling DNS entries

    Sections What is a subdomain takeover? · Prevent dangling DNS entries · Build and automate processes to mitigate the threat

  2. RFC 9989 DMARC

    Sections §4.4 · §5.3.5 · §5.4 · §7.4 · §8

[ Glossary ]

Glossary

Dangling DNS entry
A DNS relationship whose intended resource is no longer available.
Dependency owner
The team accountable for the service relationship and its retirement.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base