## TL;DR
Remove the dangling pointer before someone else claims it: find subdomains whose CNAME or NS records point at services you no longer use, confirm the target is unclaimed or controlled by someone else, delete the DNS record or reclaim the service, and then check what mail was sent as that subdomain while it was exposed. A claimed dangling subdomain lets an attacker publish their own SPF and DKIM under your name, so their mail passes DMARC as you, honestly and completely.

```text
dangling dns record on retired subdomain lets attackers send dmarc-passing mail as us
```

## Use this when
- A subdomain you retired still resolves to a third party service you cancelled.
- Mail or a website claiming to be that subdomain appears, passing authentication checks.
- A DNS audit or a subdomain takeover scanner flags a dangling record.

## Not for this skill when
- The subdomain is active and the service is yours, but mail fails authentication. That is a normal alignment fix.
- Someone registered a lookalike domain. You do not control that DNS; use takedown and filtering routes.

## Steps
1. Inventory subdomains with CNAME or NS records pointing outside your own infrastructure and match each to a current service owner. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every external pointing subdomain has an owner or is flagged as orphaned
2. For each flagged name, test whether the target service resource still exists and is yours, following the provider claim check safely. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: each flagged name is classified as claimed by you, unclaimed, or claimed by another party
3. Delete the dangling DNS record, or reclaim the service name where deletion is not possible, starting with any name flagged as claimed by another party. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the record no longer resolves to the foreign service
4. Search mail logs and DMARC reports for sending as the exposed subdomain during the exposure window. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: any mail sent as the subdomain in the window is listed and assessed
5. Add subdomain review to your decommissioning checklist so cancelling a service always includes removing its DNS. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the checklist shows the DNS removal step added

## Why it happens
Subdomain takeover is a bookkeeping failure with cryptographic consequences. The DNS name is yours, so anything published under it inherits your trust. When the service at the end of the pointer is released, whoever claims that service name next controls a slice of your namespace, including the ability to publish mail authentication that receivers will honour. The records look harmless in a zone file, which is why they survive years after the project that created them ended.

## Variants and edge cases
### dangling dns record retired subdomain attackers send dmarc passing mail
The full consequence wording from the incident.
### subdomain takeover dangling cname unclaimed service mail spoof
The takeover term variant.
### stale cname subdomain hijack spf dkim attacker controlled fix
The authentication angle variant naming the honest pass.

Compatibility: DNS zone management, subdomain takeover scanning tools, DMARC aggregate reporting.

Edge cases to check:
- NS delegations are the highest risk dangling records because the whole subdomain zone, including mail records, is controlled by the other party.
- After cleanup, keep the retired name in your DMARC reporting view for a while; late reports can reveal how long the exposure was used.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Stg-SjgZj67Az9qMqtbGcA