Two DKIM Signatures, Two Body-Hash Failures

The message arrived with two cryptographic signatures attached, and both of them said the same thing: this is not the body I signed.

The subject announced a notice of payment for a return merchandise authorization request. The recipient was an outside sales representative at a mid-size building materials distributor, someone whose week already includes vendor paperwork and product returns. The sender alias read like a consumer electronics brand, and the return path belonged to a third-party warranty-payment platform. The pretext fit an ordinary workday.

The Authentication-Results header fit nothing at all. SPF passed. DKIM failed twice. DMARC failed under a reject action. Composite authentication came back as none with reason code 460. And the message landed in the mailbox anyway.

Two Signatures, One Broken Body Hash

A DKIM signature is not a single assertion. It covers a chosen set of headers and, separately, a hash of the message body. A receiving server recomputes that hash from the body it received and compares. When the headers verify but the body hash does not, the failure is specific: the signature is intact and the key resolved correctly, but the content in hand is not the content that was signed.

This message carried two DKIM signatures. One was applied by the domain in the From header, the other by the cloud email service that relayed it outbound. Both resolved their keys. Both failed with the identical parenthetical reason, body hash did not verify.

Two independent signers, two independent keys, one identical complaint. Whatever happened to that body happened after both signatures were applied and before the final receiving system checked them.

What a Body-Hash Failure Proves, and What It Does Not

This is where threat write-ups overreach, so it is worth being precise. The tempting conclusion is in-transit tampering: someone intercepted the message, swapped a link or rewrote the payment instructions, and the hashes caught them. That is a real attack pattern, but it is not what this evidence establishes.

A dual body-hash failure this clean has a more common and usually benign cause: an inline email security product modifying the body before delivery. Gateways rewrite URLs into click-time protection wrappers, inject external-sender banners, and reformat markup. Each edit changes the body, and a changed body invalidates every body hash covering it, regardless of who signed it. This message traveled through exactly that kind of appliance, between the sending service and the recipient's Microsoft 365 tenant, and the sending service also re-wrapped its own outbound link in a click-tracking domain.

So the honest finding is not that an attacker altered this message. It is that the cryptographic chain of custody broke at every checkpoint, leaving the recipient's mail system no way to confirm the body was what either signer intended, whether the change was malicious or an artifact of the stack it passed through. Integrity you cannot verify is integrity you do not have, and the pretext underneath was still a request to click and claim money.

The Sending Domain Was Not a Lookalike

The other reflex worth resisting is assuming a domain that fails authentication must be disposable. This one was the opposite. The From domain was registered in the late 1990s, more than two decades before the message was sent, and it sits behind a corporate brand-protection registrar with a privacy-shielded registrant. That is the profile of a defended, long-running commercial domain, not a lookalike spun up for a campaign. Domain-age and registrar heuristics returned a clean read, and they were right to.

That combination is the uncomfortable part. A well-aged, brand-protected domain publishing a strict DMARC policy and sending through mainstream cloud infrastructure with a passing SPF is about as reputable as a sender profile gets on paper. The authentication result underneath it was a total failure. Reputation and cryptographic verification pointed in opposite directions, and reputation is the signal most filters weight more heavily.

When Two Gateways Read DMARC Differently

There is a second finding buried in these headers, and it may be the more actionable one.

Two inline layers evaluated this message and recorded two different DMARC verdicts. The upstream gateway logged the DKIM failure and a DMARC result of none, meaning it either did not find or did not apply a policy for the From domain. The downstream evaluation logged a DMARC failure with an override action against the domain's published reject policy. RFC 7489 specifies one algorithm, yet the same message and the same published record produced two answers.

The practical consequence: if a security team pulls DMARC telemetry from one layer while enforcement happens at another, the two datasets will not agree, and traffic that looks compliant in one console appears as a failure in the other. Anyone running DMARC monitoring and enforcement across a multi-gateway path should establish which verdict is authoritative before tuning on either. It also explains the delivery: the domain asked for rejection, the message failed, and it arrived anyway, because no single layer both observed the failure and enforced on it.

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

Why Behavior Had to Carry the Verdict

Set aside everything the authentication stack could not settle, and what remains is a payment notice from an unknown sender to a sales representative who does not process refunds, asking for a click to claim money. The link scanned clean, there was no attachment, and no artifact-based check had anything to bite on.

Themis, the agentic AI analyst on the IRONSCALES platform, scored the message as a credential-theft attempt at 65% confidence, the incident auto-resolved as phishing, and the affected mailbox was quarantined after delivery. Sixty-five percent is a moderate score and should be reported as one. It reflects a genuinely mixed signature: credible infrastructure, a financial-claim pretext, and no established sender relationship. Adaptive AI that models normal sender behavior per recipient is what produces a defensible call in that middle band.

The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds. A refund notice to a sales rep is a 21-second decision, and none of the header evidence above reaches the recipient before that click.

MITRE ATT&CK Mapping

The delivery maps to Phishing (T1566), specifically Spearphishing Link (T1566.002), routed through legitimate third-party sending infrastructure behind a financial-claim pretext. CISA phishing guidance treats this class, a payment lure riding trusted delivery infrastructure, as the phase to interrupt first.

Indicators of Compromise

What to Change

Read a body-hash failure as an integrity gap, not a verdict. Do not call it proof of tampering, and do not dismiss it as gateway noise. Treat it as a message whose content cannot be attributed to any signer, then let the pretext and the sender relationship decide.

Reconcile authentication verdicts across every inline layer. If mail passes through more than one security product, confirm that each evaluates and reports authentication the same way, and know which verdict drives enforcement. A reject policy no layer enforces is a policy in name only.

Score the middle band with behavior, not artifacts. Reputation gave this sender a pass, cryptography failed it completely, and link scanning found nothing. What was left was behavioral: an unknown sender, a payment claim, and a recipient with no reason to receive one.

The durable lesson is smaller than the headline. Two failed body hashes did not reveal who broke the message. They told the receiving system that nobody could vouch for what it was holding, and that alone is reason enough to slow a payment request down.