SPF Passed. DMARC Passed. DKIM Didn't. What That Combination Actually Means.

The email looked like a routine supplier onboarding request. A financial analyst at a well-known investment firm had already exchanged several messages with a finance administrator at a regional public utility authority. The thread had a real subject line, real reply history, and a real Point72 signature block with a Stamford, CT address and direct phone numbers. The request: complete a W-9 form and provide ACH banking instructions for direct deposit setup.

SPF passed. DMARC passed. Every gateway in the relay chain gave it a green light.

The DKIM body-hash verification failed. That single data point told a different story.

When the Cryptographic Seal Breaks

DKIM works by signing a cryptographic hash of the message body at the moment of send. The signing server hashes the content, encrypts that hash with its private key, and embeds the signature in the message headers. When the receiving server evaluates the message, it recalculates the body hash from the content it received and compares it against the decrypted signature.

If they match, the body is intact. If they don't, something changed the content after it was signed.

In this incident, the ARC-Authentication-Results header at the final Microsoft Exchange hop showed dkim=fail (body hash did not verify) header.d=point72.com. Separately, the ARC chain reported cv=fail, meaning the chain of authenticated forwarding hops was broken. These two results together are not ambiguous: the message body that arrived at the recipient was not the message body that was originally signed by the Point72 mail infrastructure.

The relay chain ran through Proofpoint (mx0a-001f6201.pphosted.com at 148.163.157.251, permitted by Point72 SPF), then through Barracuda ESS (outbound-ip77a.ess.barracuda.com at 209.222.82.241), then through Microsoft Exchange Online frontend infrastructure before reaching the recipient's M365 mailbox. Multiple security gateways handled this message. At least one of them modified the body.

The BEC Payload Inside the Authentic Shell

The social engineering underneath the authentication anomaly was well constructed. The attacker (or a modified relay message acting on behalf of a compromised account) presented as a financial analyst in an estate management role at a legitimate hedge fund. The email thread had prior message references and realistic in-reply-to chains. The request followed an established vendor onboarding pattern: complete a W-9 in locked PDF format, provide ACH banking instructions on company letterhead or signed by an authorized officer, with the beneficiary name matching the invoice remit-to name.

This is textbook business email compromise. According to the FBI's 2024 Internet Crime Report, BEC losses exceeded $2.9 billion in the United States alone, with invoice and payment fraud representing the most consistent attack pattern across industries (FBI IC3, 2024 Internet Crime Report). The finance administrator targeted here was the Assistant to the CFO, a role with access to payment processes and vendor onboarding authority. Targeting was not accidental.

One additional anomaly surfaced in the attachment: an embedded PNG file carried branding from the recipient organization, not the sender. A SCWA (the target utility) logo appeared inside an email ostensibly from a Point72 financial analyst. That kind of branding mismatch can indicate a prior communication was harvested and repurposed, or that the attacker had access to prior correspondence and assembled this message from components of earlier legitimate exchanges.

The Verizon 2024 DBIR found that 68% of breaches involved a human element, and social engineering attacks on finance personnel consistently rank among the highest-impact entry points (Verizon DBIR, 2024). An Assistant to the CFO receiving a plausible onboarding request from a known counterparty with a reply thread is a scenario where human verification instincts are actively suppressed by apparent legitimacy.

See Your Risk: Calculate how many BEC attempts your current gateway is missing

What Every Gateway in the Chain Missed

Here is the authentication picture that each security gateway evaluated:

• SPF: PASS. The sending IP (148.163.157.251) was authorized by point72.com's SPF record.
• DMARC: PASS. The visible From header aligned with the SPF-passing domain.
• DKIM: FAIL (body hash did not verify).

SPF checks that a sending server is permitted to send on behalf of a domain. It says nothing about message content. DMARC checks that the visible From address aligns with either a passing SPF or DKIM result. In this case, DMARC passed on the strength of SPF alone, since DKIM failed. Neither SPF nor DMARC provides any guarantee that the message body is what the original sender wrote.

Most security gateways are configured to accept messages that pass DMARC. That is a defensible default in the aggregate. But for high-risk request types (any email requesting banking details, ACH routing, wire instructions, or tax documents), DKIM body-hash failure should trigger an additional review layer, not a pass.

The MITRE ATT&CK framework categorizes this pattern under T1566.001 Spearphishing Attachment and, where relay compromise is the vector, intersects with T1534 Internal Spearphishing and T1586.002 Compromise Accounts. When the body-hash failure results from a compromised intermediate relay, the attacker never needs to spoof the sender domain at all.

Themis flagged the behavioral risk here based on the combination of signals: the payment request pattern, the DKIM/ARC failure, the branding mismatch in the attachment, and the recipient's financial role. The message was quarantined across four mailboxes before any user acted on the ACH request.

Indicators of Compromise

The Right Response to a Broken Seal

Authentication failures on payment requests deserve a different response than authentication failures on marketing emails.

When DKIM body-hash verification fails on an email requesting financial information, the correct posture is: treat the body content as unverified. Call the requester at a number obtained from official sources, not from the email. Do not use phone numbers embedded in the message or in the reply chain. Do not forward the banking instructions request to a colleague before completing that verification.

For security teams, a few changes to detection posture help:

1. Tag DKIM body-hash failures on payment-related emails for human review. DMARC pass is not sufficient for financial action items.
2. Monitor for ARC cv=fail in combination with high-risk request patterns. The two together are a strong indicator that body content cannot be trusted as original.
3. Treat attachment branding mismatches as a secondary signal. When the embedded graphics in an email belong to a different organization than the sender, something in the message construction is off.
4. Ensure DMARC management policies include alerting on body-hash failures, not just alignment failures. Most DMARC implementations are configured to alert on authentication failures that affect deliverability. DKIM body-hash failures may not trigger those alerts if DMARC still passes on SPF.

The Microsoft Digital Defense Report 2024 noted that business email compromise remains one of the most financially damaging threat categories, with attackers increasingly relying on legitimate infrastructure and authentication chain ambiguity to evade detection (Microsoft Digital Defense Report 2024). This case is a precise example of that pattern: a message that passed every policy-based check except the one that actually verifies content integrity.

The IBM 2024 Cost of a Data Breach Report puts the average BEC-related breach cost at levels that make out-of-band verification a very cheap countermeasure by comparison (IBM Cost of a Data Breach Report 2024). One phone call to a known contact number would have closed this attack entirely.