Fully Signed, Fully Passed: The Reply-To Was the Payload

A senior certification executive at a professional certification and credentialing organization received a message in mid-August 2026 that asked for almost nothing. One line of body text, no attachment, no link, no deadline: "I'm following up on the email I sent to you previously in regards to my RFQ emails or do I resend to you?" The subject line was a pleasantry about the weekend. The sender was a genuine mailbox at a European regional government body, and every cryptographic control agreed the message was exactly what it claimed to be.

The interesting part is not that authentication passed. It is that authentication had nothing to object to, because nothing was forged. The message really did originate inside that government body's own mail flow, and it really was signed on the way out by that organization's own key. What the signature covered, and this is the entire case, included the Reply-To header, which pointed somewhere else.

The Header That Was Under Signature

A DKIM signature declares, inside the signature itself, which headers it protects, and altering any listed header in transit breaks validation. In this message, the signed-header list for the government domain's signature explicitly named the reply-to field, and the signature validated anyway.

That single detail collapses the usual explanations. The covert reply address was not appended by a compromised perimeter device and not injected downstream after the message left the tenant. It was present in the message as composed, before the sending organization's own gateway signed it. Either the mailbox was under attacker control, or an internal mail flow was subverted upstream of signing. The record supports both readings and does not distinguish them.

The Reply-To field carried two addresses. The first was infodesk@frontdesk-investment[.]com. The second was the genuine government mailbox. Attacker first. Most mail clients populate a reply from the full reply list, so a reply composed without expanding the recipient field goes to the attacker as well as the real sender. The address is not invisible: anyone who inspected the recipients on their draft would have seen both. Essentially nobody does.

Two Signatures and an Unbroken Chain

The authentication results read like a reference implementation. DKIM passed twice, once against the government domain's own selector and once against the sending organization's Microsoft tenant default domain. DMARC passed for the header From domain under a published policy of quarantine. ARC passed across the full relay chain. The composite authentication verdict came back clean at maximum confidence.

None of that is a contradiction or a bypass. DMARC, as specified in RFC 9989, evaluates alignment between the visible From domain and an authenticated identifier. Its scope stops there. DKIM proves a covered header was not modified between signing and delivery; it has no view on whether that header is benign. A signed header is authentic. Authentic and safe are different properties, and this attack lives in the gap.

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

The SPF Failure That Was Not a Signal

SPF failed at the final hop. Read in isolation that looks like the tell, and it is not. An earlier Received-SPF record in the same header stack shows a pass for the same sender upstream. The trailing failure is the sending organization's outbound security relay re-sending from its own address space, which the government domain's SPF record does not cover. DKIM travels with the message, so both signatures survived the relay while SPF alignment did not.

The discriminating question for any mixed authentication result is whether the message authenticated at the last hop before the recipient's own security stack touched it. Here it did. Reading the trailing SPF failure as the attack signal points at the wrong thing; reading the clean DKIM and DMARC as an all-clear misses the attack entirely.

A Reply Path Whose Destination Could Not Be Resolved

A WHOIS lookup on the reply domain returned no data at all. That is consistent with a domain that is unregistered, expired, or shielded behind a privacy service, and the record cannot tell those apart. So the honest description is narrow: the reply channel had been redirected to a domain whose registration state could not be established at analysis time. There is no evidence of a live credential-harvesting site behind it.

That ambiguity is part of why the technique works. A hijacked reply path does not need working capture infrastructure on the day the lure lands: the capture side can be burned already, staged for later, or hidden from lookup. What the attacker needs is a person who replies. If the domain does not resolve, the reply bounces, the recipient reads it as a delivery problem, and a resend becomes the natural next step.

What Actually Caught It

Our Adaptive AI analyst, Themis, scored the message at 62% confidence and surfaced it under a vip-recipient label, flagging the phrasing and structure as matching patterns associated with phishing rather than acting on a payload verdict. There was no malware verdict and no malicious URL verdict, because there was no malware and no malicious URL. Community reputation signal from 36,000+ security professionals across 18,000+ organizations added weight, drawing on how comparable messages resolved elsewhere.

Microsoft's own filtering disagreed with itself. The same header block that recorded a clean composite authentication verdict also carried a spam confidence level of 5 and a content category of bulk spam. The authentication layer had nothing to reject; the content layer was uneasy. With a first-time-sender flag and a payload-free reply-provocation body, the behavioral picture was clear while the cryptographic picture stayed spotless. One mailbox was affected, the message was mitigated, and no user action was recorded before mitigation.

Why There Was No Infrastructure to Block

Consider what a blocklist would have to target. The sending domain belongs to a real government body that is a victim here, not an attacker, so blocking it punishes a bystander and breaks legitimate correspondence. There is no attacker-registered sending domain, no lookalike, no relay, no URL to sandbox, no attachment to detonate. The only attacker-controlled string in the message is a reply address in a header that most triage workflows never surface.

That is the shape of modern business email compromise. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing at 16% of initial access vectors, and the 2025 FBI IC3 Annual Report records $3,046,598,558 in reported BEC losses. Those are attacks that lean on trust and process rather than tooling, which is exactly what a signed reply-path redirect does. CISA's phishing guidance and the NIST definition of phishing both frame the problem around deception of the recipient, not malicious code.

The practical control is unglamorous. Surface reply-path divergence at triage as a first-class signal: any inbound message whose reply domain does not match the From domain deserves a look, and one carrying two reply addresses deserves more. Enforcement on the sending domain will not help, because the sending domain did everything right.

Indicators of Compromise

MITRE ATT&CK Mapping

The Header Worth Auditing

Reply-path redirection usually leaves something to grab onto: a lookalike domain, a fresh registration, a relay that broke alignment. This case removes all of it. The sender was real, the signatures were real, the policy was enforced, and the chain of custody held from composition to delivery. The attacker did not defeat authentication. The attacker used it, then wrote one line and waited.

So ask your triage workflow one question: when an analyst opens a message, does the reply domain appear next to the From domain, or does somebody have to go looking for it?