Retired Brand, Real Signature: Extortion in a DMARC Gap

A shared scheduling mailbox at a workers'-compensation and care-management services company received an email late last year with the subject "Data leak !". There was no link to click, no executable, no payment portal. There were five inline images presented as proof of a breach, a claim that 700 gigabytes of the company's data was about to be published, and one peer-to-peer messenger ID as the only channel for negotiation.

The message also authenticated. SPF passed. DKIM verified. And DMARC failed anyway, for a reason that has nothing to do with extortion and everything to do with a corporate rebrand.

The Message Authenticated for a Domain Nobody Was Reading

The envelope sender and the DKIM signing domain both belonged to an enterprise analytics vendor that had recently rebranded, and both pointed at that vendor's current domain. The message left through an egress relay that domain genuinely authorizes in its own SPF record, and the signature verified against a key it publishes. Two independent checks, both real, both passing, both aligned to each other.

The address rendered in the visible From header was different: it sat on the vendor's retired pre-rebrand domain, a separate domain belonging to the same company.

That single mismatch is the whole failure. DMARC does not simply ask whether SPF or DKIM passed. It asks whether at least one of those results aligns with the domain in the header From, the one a person actually reads, the alignment requirement carried forward in RFC 9989. Here the authenticated domain and the displayed domain were two different assets of one company, so there was nothing to align. The header recorded dmarc=fail action=none, and no enforcement followed.

Then Microsoft's composite authentication, which blends explicit results with sender reputation and history rather than reading the DMARC verdict alone, returned compauth=pass, and the message reached the inbox instead of stopping at the gateway. A DMARC failure that nothing enforces, sitting next to a composite pass, is a delivery formula rather than a warning.

The security platform's own impersonation classifier did not fire either, which is less a miss than a definitional problem. Impersonation heuristics hunt for lookalikes, homoglyphs, and freshly registered cousin domains. Both domains here are genuine, both belong to the same organization, and neither is a forgery. The mismatch is real and invisible to a check built to catch fakes.

Why a Rebrand Becomes an Authentication Surface

The record does not say whether the legacy brand in the visible sender was chosen deliberately or a leftover artifact of a stale account profile, and it does not say how that mailbox came to send extortion mail at all. Both readings land in the same place operationally.

A rebrand splits one identity across two domains, often for years. The new domain gets the attention: policy records, signing keys, gateway configuration, aggregate reporting. The old domain keeps the recognition: it stays alive for redirects and historical addresses, and it keeps looking familiar to everyone who reads it. Anything that leaves with the legacy domain in the header From authenticates for the current domain and fails alignment against the legacy one. That is the predictable steady state of a migration nobody monitors on both sides, which is the argument for keeping DMARC aggregate monitoring pointed at a retired brand domain for as long as it resolves.

The vendor here is a bystander, not the attacker. Its real infrastructure carried this message and its brand supplied the credibility. That is the same position any organization occupies when its authenticated mail is turned against a third party.

An Extortion Note With Nothing to Detonate

The body is short, informally written, and grammatically broken in the way bulk extortion usually is. It opens with a casual greeting, asserts that the recipient's information was obtained through a third party's weak security, puts the haul at "700 gig," promises a leak, and directs all contact to a qTox messenger ID. We are withholding the third-party firm the attacker named, because nothing in the record supports the claim that a breach happened there. It is an assertion, not a finding.

There is no URL anywhere in the message and no executable content, so URL sandboxing, link rewriting, and attachment detonation have nothing to work with. The negotiation channel is a peer-to-peer messenger ID rather than a payment page, so there is no hosted infrastructure to report, seize, or reputation-score. Structurally this is spearphishing via attachment in service of financial theft.

See Your Risk: Calculate how many threats your SEG is missing

The Proof Was Real, and It Belonged to Someone Else

The obvious assumption about extortion proof is that it is fabricated, a kit template with plausible-looking fields. Two of the five images were inspected directly, and that assumption was wrong.

They are recycled documents containing a third party's unrelated personal injury records: genuine claim paperwork and correspondence about a private individual, nearly a decade old, with no connection whatsoever to the recipient organization. We are publishing nothing from them, no names, no identifiers, no detail.

The documents are not fake, so a recipient who opens them sees real, sensitive, verifiable-looking paperwork and feels the threat land. But they are also not proof of the claimed breach. They are somebody else's exposure from an unrelated incident years earlier, reused as generic leverage against a target chosen for its industry rather than for anything the sender actually holds. This recipient handles claim records for a living, so records are the shape of evidence that looks native.

Only opening the attachments settled it: the extortion text alone supports the bluff read and the confirmed-breach read equally well, and both are wrong.

What Actually Flagged It

No file verdict or URL verdict could settle this message, so detection came from behavior and context. Our Adaptive AI scored it at 86% confidence, labelled it extortion aimed at a high-value recipient, and resolved the incident as phishing.

The signals here are all contextual: a first-time sender with no correspondence history anywhere in the tenant, extortion language patterns, an authentication result that does not match the identity on display, a shared operational mailbox as the target, and an out-of-band contact channel with no infrastructure behind it. Four mailboxes were touched across two waves, including an internal forward days later by a recipient escalating it. All four instances were quarantined and mitigated.

The 2026 Verizon Data Breach Investigations Report ties 62% of breaches to the human element and tracks pretexting as 6% of initial access vectors, and the FBI's 2025 IC3 Annual Report records $20.877 billion in reported losses, a 26% increase year over year. CISA's phishing guidance and the NIST definition frame the problem the same way: the technique is social, and technical controls are supporting evidence rather than a verdict.

Indicators of Compromise

MITRE ATT&CK Mapping

The Takeaway

Alignment is the part of email authentication that answers the question a human is actually asking: does the name on display belong to the domain that signed the message. A rebrand breaks that answer quietly, because the old domain keeps every bit of its familiarity and loses all of its enforcement relevance. If your organization carries a legacy brand domain, watch its aggregate reports as closely as the new one, and treat a DMARC failure with nothing enforcing it as a finding rather than noise. And when a threat arrives with proof attached, verify it against your own logs before believing the sender or your own instinct that it must be fake.