Your Own Mailing List Signed the Phishing Email

In late August, four mailboxes at a regional equipment rental company received the same message in the same second. It announced that a spreadsheet had been shared with them, and it carried one button. By the time it landed, the authentication line attached to it read like this: SPF pass, DKIM fail, DMARC fail, ARC pass.

Any analyst who has run a mail platform recognizes that combination. It is what a mailing list does to a message. Envelope rewritten, signature broken, alignment lost, an intermediary vouching for what it saw upstream. It is close to the most tuned out alert class in email security, because almost every time you look, it is your own infrastructure being slightly inconvenient.

This time the list was the delivery mechanism, and the signature that failed belonged to the rental company itself.

The Broken Signature Was the Recipient's

The message was not addressed to a person. It was addressed to the company's own accounting distribution list, hosted as a group on the company's Google Workspace tenant. The group was configured to accept the post, and it did.

What happened next is ordinary mailing list behavior applied to a forgery. The group rewrote the envelope sender to its own bounce address on the company's domain, applied a fresh DKIM signature using the company's own domain and the standard Workspace selector s=google, sealed the authentication results it had observed upstream into an ARC chain three seals deep, and delivered the result to all four members.

At the receiving hop the arithmetic came out like this. SPF passed, because the envelope now belonged to the group and the sending address was Google's. DKIM failed, because the signature the group had applied moments earlier no longer verified once the group appended its own list footer. DMARC failed, because the header From still pointed at an outside domain that no longer aligned with the rewritten envelope. A second, quieter result, dara=fail, recorded the same alignment problem from another angle. And ARC passed, faithfully attesting that an earlier hop had authenticated cleanly.

Every one of those results is correct. Read individually, every one is boring. Read together, they describe a message that arrived from outside the organization and left the organization's own platform wearing the organization's own signature.

An External Post Becomes an Internal Fan-Out

The upstream hop is what made the failure downstream so convincing. The message left the outbound infrastructure of a long established Japanese consumer ISP, passed SPF from that provider's own mail server, and carried a valid DKIM signature for that provider's domain, so the first hop recorded SPF pass, DKIM pass and DMARC pass. This was not a lookalike domain and not a spoof. Something authenticated to a real account on a real consumer mail platform and sent from it. Whether that account was stolen or simply registered by the operator is not in the record, and the header From and the envelope sender do not even name the same mailbox, so no individual can be blamed for the send. The provider is a bystander.

That is the ingredient the group converted into something that looked domestic. One inbound external message became four internally signed deliveries, addressed to the finance function, inside a single second. No compromised employee mailbox was required. The group's posting policy was enough.

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

Nothing in the Path Belonged to the Attacker

Follow the button and the pattern holds. The call to action rode a shared marketing platform click tracker, the sort any customer of that platform can generate, which redirected twice and landed on a WordPress administrative path on the website of a real manufacturing business, registered roughly six months before the attack and served by a mainstream regional host. The payload sitting under /wp-admin/css/color/ is the classic signature of a compromised content management system rather than purpose built attacker hosting, so the manufacturer is a second bystander. ATT&CK tracks that as compromise infrastructure: server, T1584.004, with the delivery as spearphishing link, T1566.002.

So there is no attacker owned sending domain here and no attacker owned landing domain. There is a consumer ISP, a marketing platform, the recipient's own Workspace tenant, and a small manufacturer's website. The lure displayed the accounting list's own address as the person sharing the file while the underlying link pointed elsewhere, which ATT&CK would file under masquerading: match legitimate name or location, T1036.005.

One detail cuts the other way. Both domains involved publish a monitor only policy, p=none, which instructs the receiver to take no action on a failure. The failures described above were never going to reject anything. They were only ever going to be logged.

What Produced the Verdict

Not the sender analysis, which had a genuinely authenticating upstream hop to work with. Not domain reputation, which had no attacker domain to score. Not link reputation in any simple sense: the tracker returned a mixed result, and both landing URLs actually scanned clean, serving placeholder content when they were fetched.

The verdict came from Themis, our Adaptive AI analyst, at confidence 80, on a link flagged malicious, suspicious language and structure, sender inconsistencies, and community reputation showing the message resembled ones already resolved as phishing in other tenants. That last input matters most, because it is the only signal in the stack that does not depend on infrastructure the attacker never owned. It comes from 36,000+ security professionals across 18,000+ organizations having already seen constructions built the same way. The 2026 Verizon Data Breach Investigations Report puts phishing at 16% of breaches as the initial access vector and the human element in 62% overall, and cases like this are why those figures resist infrastructure based controls.

What did not happen also deserves stating. No mitigation action, status or assignee is recorded against any of the four mailboxes. There is no evidence anyone clicked, and equally none that the message was quarantined or clawed back before anyone could.

Fix the Posting Policy, Not the Signature

The remediation is configuration, and it is cheap. Audit which of your distribution groups accept mail from outside the organization and restrict the ones with no reason to. An internal accounting list does not need to be reachable from the open internet, and closing that removes the fan-out mechanism entirely.

Then fix the reading. Separate the authentication failures your own lists generate from the ones outside senders generate, and when your own domain is the signer, look at what the header From says. Your own domain signing a message whose header From belongs to someone else is not forwarding noise. It is a message that came from outside and got dressed as internal on the way in. CISA's phishing guidance and the NIST definition of phishing both put the lure at the center of the control problem, and that is where this one was decided.

Indicators of Compromise

MITRE ATT&CK Mapping