SPF-Passed Email Carried an $80K Fake Vendor Invoice

An $80,650 invoice landed in an accounts-payable bookkeeper's inbox with a clean SPF pass, a real Japanese organization's domain in the envelope, and a valid-looking W-9 attached. Every technical signal a legacy gateway inspects said the message was authentic. None of it meant the sender was who they claimed to be.

The target was a food and nutrition ingredients manufacturer. The ask was a same-day wire for a balance that did not exist, framed as urgent, from a name the recipient half-recognized. There were no malicious links. There was no malware. The entire attack was social engineering wrapped in headers that authenticate cleanly, which is exactly what makes it dangerous.

A real domain and a real relay produced a real SPF pass

The envelope-from and Return-Path resolved to a long-established Japanese organization's mail domain, relayed through Canonet, a legitimate Japanese hosting provider. The relay IP was authorized in that domain's SPF record, so SPF passed. DKIM was absent, and DMARC returned bestguesspass rather than a hard alignment.

That combination is the whole trick. Sender Policy Framework (SPF) confirms only that a given IP is permitted to send mail for the envelope domain. It does not confirm that the content is honest, that the claimed billing party is real, or that the money goes where the invoice implies. Attackers who route through a reputable third-party domain inherit its sending reputation for free.

The display name added the second layer. It closely mimicked, without exactly matching, a known contact at a partner organization. This is name-recognition trust, not domain spoofing. The recipient was not asked to trust an unfamiliar address. They were nudged to trust a familiar-sounding human.

The vendor named on the invoice never sent the message

Here is where the identities stopped lining up. The attached invoice claimed to originate from a named third-party vendor. But the domain that actually sent the email had no relationship to that vendor. And the reply and remittance path pointed somewhere else entirely: a separate, newly registered, privacy-shielded domain that matched neither the sending organization nor the vendor on the invoice.

Three identities, three disconnects. The billing party on the paper, the domain in the headers, and the address collecting the reply were all different entities pretending to be one relationship. That mismatch is the signal. Pure authentication cannot see it, because each individual identity looks plausible in isolation.

This pattern sits at the seam between business email compromise (BEC) and vendor email compromise (VEC). No genuine vendor mailbox was taken over. The attacker fabricated a vendor identity, borrowed an authenticated relay, and impersonated a trusted contact to make the fiction hold together long enough to move money. The 2024 Verizon Data Breach Investigations Report (DBIR) puts the median business email compromise transaction near $50,000, so an $80,650 demand is squarely in the fraudsters' proven range.

The W-9 was a legitimacy prop, not a payment instrument

The most instructive artifact was the attachment that did nothing. A programmatically generated W-9, carrying a real-format employer identification number, was attached solely to look official. It held no bank or routing details. Neither did the invoice PDF itself.

That is deliberate. Bank instructions are the riskiest part of the con, the detail most likely to trigger a second look or a verification call. So they are withheld from the first message. The opening move establishes a credible vendor relationship using bureaucratic paperwork. Once the target engages, the attacker supplies remittance details in a follow-up, often with fresh urgency. A W-9 attached to a first-contact invoice from a vendor you did not onboard is not reassurance. It is a tell.

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

Where authentication stops, intent analysis begins

A secure email gateway (SEG) evaluating this message finds an SPF pass, a reputable relay, no malicious URL, and no attachment payload, then delivers it. IRONSCALES platform data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and messages like this one are why. There is nothing on the traditional checklist to fail.

Themis, our Adaptive AI, reads the message the way a suspicious human would. It correlates the vendor identity on the invoice against the domain that actually sent the mail against the domain requesting the reply, and flags the fact that none of them belong to the same party. It weighs the same-day payment urgency, the first-contact status of the sending relationship, and the freshly registered, privacy-masked remittance domain as reinforcing risk signals rather than isolated data points. That behavioral correlation is what catches identity fraud that authentication launders as clean.

CISA's phishing guidance stresses interrupting the attack cycle before the payment stage, and NIST defines phishing precisely around this kind of deception through trusted-looking communication. The Microsoft Digital Defense Report 2024 similarly documents financially motivated actors leaning on authenticated infrastructure and identity abuse over malware. The direction is consistent: the payload is the impersonation itself.

Indicators of Compromise

The technique maps cleanly to MITRE ATT&CK: T1566 (Phishing) for the delivery, T1656 (Impersonation) for the borrowed contact and vendor identities, and T1585 (Establish Accounts) for the freshly registered remittance domain. IRONSCALES protects 35,000+ security professionals across 17,000+ organizations, and vendor-invoice fraud like this is one of the most common patterns our BEC protection surfaces.

Correlate identity, not just headers

Treat a clean SPF pass as a starting point, never a verdict. Before any wire, verify three things independently: that the vendor named on the invoice is one you actually onboarded, that the domain that sent the message belongs to that vendor, and that the remittance destination matches records you already hold, not instructions supplied in the same thread. When the paperwork, the sender, and the payee point at three different entities, the authentication was never the answer. The identity mismatch was the attack.