A Valid DKIM Signature Over an Unauthorized Message

The outer email had nothing in it. No request, no link, no invoice, no closing line. The visible body of the message that landed in a senior executive's mailbox at a mid-size food and beverage products company in mid-August contained one banner image and Microsoft's own first-contact notice, the strip that reads "You don't often get email from this sender," along with its three boilerplate explanatory links. Every one of those links resolved to Microsoft properties and scanned clean, because they belonged to Microsoft.

The subject promised a quarterly earnings reconciliation and a benefits update. The payload was an attachment: a single message file named Earnings_Adjustment.eml, roughly 188 KB, on which the antivirus engine returned a verdict of clean.

None of that is the interesting part. The interesting part is what the recipient's stack saw when it evaluated authentication.

One Message, Two Accurate Authentication Verdicts

The header set that the receiving tenant acted on was unambiguous. SPF passed. DKIM passed, with a verified signature and a real selector aligned to the sending domain. DMARC passed against a published policy of quarantine at full percentage, with no action taken. Composite authentication passed with reason 100, which is Microsoft's strongest available confidence marker.

One hop earlier, the same message had failed all of it.

The connection that introduced this message came from a host with no reverse DNS record, geolocated in Great Britain, greeting the receiving server with the HELO string speedy-negotiation. That host was not authorized to send for the domain the message claimed. SPF returned an explicit failure. The message carried no signature at all, so DKIM was simply absent. DMARC failed and recorded an action of quarantine. Microsoft's own pre-trust-boundary spam report on that hop marked the sender as having a nonexistent reverse DNS entry and filed the mail as outbound spam.

Both verdicts are true. They describe different hops.

What Happened In Between

The failing connection was not delivered to the recipient. It was submitted into the claimed sending domain's own Microsoft 365 tenant, and the record shows it processed there: through that tenant's regional Exchange Online frontend, its categorizer, and a mailbox database inside the same tenant's own infrastructure. It then left through that tenant's outbound protection service.

That is the whole mechanism. When Exchange Online relays a message outbound on behalf of a tenant, it sends from Microsoft-operated addresses that the tenant's own SPF record authorizes, and it applies the tenant's own DKIM signature. Both of those things happened correctly here. The signature was computed over this exact body, by legitimate infrastructure, and it verifies. What an outbound path never does is re-examine whether the thing it is signing should have been accepted in the first place.

The record does not reveal how the unauthenticated host got its message accepted into that tenant's mail flow. It could have been stolen credentials, an exposed submission secret, or a misconfigured connector. The headers cannot settle that, so no one should assert it. What the headers do establish is that the submission failed authentication against the domain it claimed, and was processed anyway.

Why This Is Not an ARC Problem

It is tempting to file this alongside the familiar pattern where a downstream appliance re-seals a message and a receiving stack honors the vouch. That is not what happened, and the difference is the point.

An ARC seal is a trust assertion. An IP allow-list is a policy exception. Both are decisions a defender can review, tighten, or revoke. Here there was no decision to revoke. The ARC chain did validate, and it faithfully carried the original failing result forward at index one, which is where the evidence survives. But the pass the recipient's stack recorded did not come from ARC. It came from a freshly generated cryptographic signature over unauthorized content, produced by the very domain whose authorization was the open question.

As RFC 9989 makes explicit, DMARC evaluates alignment between authenticated identifiers and the visible From domain. It was designed to answer whether a domain's infrastructure handled a message. It was never designed to answer whether that domain's infrastructure was supposed to.

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

The Payload Was Pixels, Two Layers Down

The attached message file was not a forwarded email. It had no Received headers at all, which no genuinely transmitted message lacks. Its header block was plain text, written to read as internal HR correspondence from an address at the recipient's own domain.

Rendered, it produced a branded compensation-update notice addressed to the recipient by mailbox name, announcing a salary adjustment and carrying a fabricated reference identifier assembled from her address and the date. The instruction was to scan an embedded QR code to view the increase.

Decoded, that QR code resolved to a subdomain of a privacy-shielded domain registered roughly four months before the send, fronted by Cloudflare, with the recipient's own email address already populated as a query parameter. That is a credential-harvesting landing page with the identity field pre-filled.

It appeared in no link extraction anywhere in the pipeline. The destination existed only as image data inside an HTML body inside an attached file, which is precisely why QR-based lures keep working against stacks that are otherwise good at URLs.

What Actually Flagged It

Not much, and worth being honest about. Themis surfaced the message at 53 percent confidence with the labels Credential Theft and VIP Recipient, and a human analyst approved that call manually rather than the platform resolving it automatically. Detection rode on behavioral and language signals in the outer message plus the seniority of the recipient, because there was nothing else to ride on. The attachment scanned clean. The links were Microsoft's. The authentication verdict was flawless. The quarantine action that followed is recorded with a status of error, which is its own finding.

The 2026 Verizon Data Breach Investigations Report puts phishing at 16 percent of breach initial-access vectors, and credentials somewhere in the chain of 39 percent of breaches. Those numbers hold up because the delivery layer keeps producing cases like this one, where every gate a defender configured returned the correct answer to a question that turned out to be the wrong question.

How to Read a Chain Like This

Read the earliest hop, not the last one. On a Microsoft path, that means the authentication result recorded before the trust boundary and the ARC result set sealed at index one. Both preserve the original verdict underneath a clean final pass, and both were readable here.

Then treat a clean pass as a statement about custody, not intent, a framing that both CISA's phishing guidance and the NIST definition support. Authentication proved that a real tenant relayed this message, and that was entirely true. It never claimed the tenant authorized it.

The consultancy whose tenant re-signed this message is a real, active business with no connection to food industry payroll. Its infrastructure was turned against a third party without its knowledge. It is a victim here, not a participant, which is why nothing identifying it appears below.

Indicators of Compromise

MITRE ATT&CK Mapping