It Passed SPF, DKIM, and DMARC. It Was Still a W-2 Heist.

The request landed in a payroll inbox in the middle of an ordinary afternoon. The subject line read, blandly, an audit note about 2025 records. The body was two sentences: please send the 2025 W-2 PDFs for all company employees at every location today, and I will take care of uploading them to the secure portal. It was signed with only a first name, the same first name as a leader the recipient's organization would recognize.

No link to click. No attachment to open. No malware anywhere in the message. Just a polite, urgent ask for the single most sensitive file a payroll team holds: every employee's W-2, complete with Social Security numbers, wages, and home addresses. The kind of file that, in the wrong hands, becomes a season of fraudulent tax refunds and identity theft.

Here is the part that should stop you. The message passed SPF, DKIM, and DMARC. All three. Cleanly.

Authentication Said Yes. The Identity Was a Lie.

This is the gap the whole case turns on, so it is worth being exact about what those passing checks actually mean.

SPF, DKIM, and DMARC are the three pillars of email authentication. SPF confirms the sending server is authorized to send for the domain. DKIM proves the message was cryptographically signed by that domain and not altered in transit. DMARC checks that the two align with the domain in the visible From address. When all three pass, you know one thing with confidence: the message really was sent from the domain it claims.

You do not know who was sitting at the keyboard. You do not know whether the display name is honest. Authentication validates the sending domain. It has never validated the human identity asserted in the display name, and that distinction is exactly what this attacker monetized.

The From address was not a corporate mailbox at all. It was a consumer account at a Japanese internet service provider, wing.ocn[.]ne[.]jp. SPF passed for that ISP domain, DKIM was signed by that ISP domain, DMARC aligned to that ISP domain, and the composite authentication result came back at a perfect score. Every check was answered truthfully. The mail genuinely came from that ISP mailbox. The lie was never in the envelope. It was in the display name, which had been padded to embed the recipient organization's own name alongside a long junk string that shoves the real ISP address out of view in most mail clients.

The Relay Tell: Authenticated Abuse, Not a Spoof

Trace the path the message took and the mechanism becomes clear. The final submission hop shows a Google Cloud virtual machine, 35.198.205[.]129, authenticating into the ISP's mail submission server and handing off the message, which then flowed out through the provider's own legitimate mail transfer agents in Japan before reaching Microsoft for delivery.

That authenticated submission is why the signatures are valid. This is not a forged From header bolted onto random infrastructure. It is a compromised or attacker-controlled ISP account being driven from a cloud host, sending as a real, authorized user of that ISP. The provider's servers signed the mail because, from their perspective, an authenticated customer sent it. DKIM had every reason to pass. So did SPF and DMARC.

An attacker who controls one authenticated mailbox on any real domain inherits that domain's clean authentication posture for free. No spoofing required. That is the uncomfortable truth behind a growing share of business email compromise: the sending domain is legitimately authenticated, and the fraud lives entirely in the story the message tells.

Two Systems, Two Opposite Verdicts

The most instructive detail is that the receiving mail platform did not simply wave this through. Microsoft scored it a spam confidence level of 9, the maximum, tagged it high-confidence spam, and dropped it in the Junk folder with an external-sender banner attached. IRONSCALES quarantined it outright.

So one set of signals screamed danger while another reported a spotless pass. The impersonation engine flagged that the company's own name appeared in the display name of an external sender. The behavioral read caught the mismatch, the urgency, and the bulk-PII ask. Meanwhile, the authentication stack, asked only whether the domain was real and aligned, said yes.

That divergence is the whole point. A passing authentication result is not a verdict on legitimacy, and treating it as one is precisely how these messages reach people. In a tenant tuned to trust authenticated senders, or on a well-meaning admin's release of a quarantined item, that same clean SPF, DKIM, and DMARC pass is what carries the mail to the inbox. We have seen it in our own casework, where a fully authenticated message was quarantined and then released with its spam score reset. Authentication buys the attacker the benefit of the doubt.

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

The Reply-To, and a Name With No One Behind It

Two more details complete the picture. First, the Reply-To pointed to a third domain, pointdsk[.]com, different from both the ISP From address and the organization being impersonated. WHOIS shows that domain was registered roughly two hours before the message was sent, through a registrar behind a privacy shield, on Cloudflare name servers. Any reply, W-2 files included, would have flowed to attacker infrastructure that did not exist that morning.

Second, and this is where the case turns quietly grim: open-source records indicate the executive whose identity was borrowed is a former company leader who is no longer living. The attacker scraped a name that looked authoritative and never checked, or never cared, whether there was a real person to verify against. There was not. Which underscores the entire lesson. There was no live relationship for the payroll team to fall back on, no "does this sound like them" instinct that could have helped, because the identity was pure scavenged branding stapled to an authenticated ISP mailbox.

What Defenders Should Take From This

Map it to MITRE ATT&CK and it is Phishing, T1566 as the delivery, Phishing for Information, T1598 as the goal, and Impersonation, T1656 as the method. The FBI IC3 2024 Annual Report puts BEC losses above 2.9 billion dollars, and the 2026 Verizon Data Breach Investigations Report gateway telemetry shows BEC as roughly 3 percent of the email attack mix, small in volume and enormous in per-incident cost.

Two takeaways. Stop reading a passing authentication result as a clean bill of health. SPF, DKIM, and DMARC verify the domain, not the person, and detection has to weigh behavioral signals, first-time senders, display-name mismatches, third-domain Reply-To routes, and freshly registered infrastructure, alongside the auth verdict rather than deferring to it. And build an out-of-band rule for bulk PII: no W-2 batch, no payroll change, no employee-data export leaves the building on the strength of an email, no matter how authoritative the name on it looks. Verify through a known channel, every time. The name in the display line is the easiest thing in the entire message to fake, and in this case there was no one behind it at all.

Indicators of Compromise

The links in the message body pointed only to legitimate Microsoft support pages added by the receiving client, not attacker infrastructure. There was no malicious link and no attachment. The danger was a request, an authenticated envelope, and a name with no one behind it.