The DKIM Passed. Nobody Spoofed Anything.

The DKIM signature on this message passed. The key that signed it belonged to the company that received it.

That is not the surprising part. The surprising part is what failed in the same line. DMARC failed for a domain that nobody in the delivery chain owned, and it failed precisely because the operator never spoofed anything. They had the password.

A European cyber-insurance provider took delivery in the mailbox of its Chief Revenue Officer, reached through the company's own internal admin group rather than directly.

Every Identity That Authenticated Belonged to the Victim

Here is the authentication line as Google's inbound mail exchanger wrote it at delivery. DKIM pass, on the tenant-specific gappssmtp key Google issues to the organization's own Workspace domain. SPF pass, for the group's own bounce address on that same domain. ARC pass. And DMARC fail, p=NONE sp=NONE dis=NONE, against the domain in the header From, with a quieter dara=fail recording the same alignment problem from another angle.

Read it as a set. Every identity that authenticated belongs to the recipient or to a company the recipient exchanges mail with. The only one that fails is the identity the human being actually sees.

This series has already covered the mirror image of that line. In that case a company's own Google group re-signed an inbound forgery, the delivered DKIM failed because the group broke its own signature on the way out, and the closing observation was that nothing in the chain belonged to the attacker. DKIM fail plus DMARC fail plus ARC pass is the ordinary fingerprint of list forwarding, which is exactly why nobody reads that alert.

Invert the DKIM result and the whole reading flips. A verifying signature is what analysts reach for when they want reassurance. Here it sits on a message the recipient's own platform imported.

The Origin Hop Was a Login, Not a Lie

Trace it back and the reason for that pass is uncomfortable.

The first Received header records an authenticated submission: a Windows-style workstation name, an unknown reverse lookup, a client address with no relationship to the server's own network, handed to a Japanese small-business mail server running Postfix and accepted with ESMTPA. The trailing A is the whole story. SMTP AUTH succeeded. Whoever connected had working credentials for a real mailbox there.

So the upstream authentication state was not merely plausible, it was clean. Sealed at the third ARC instance: SPF pass on the sending domain's own envelope address, DKIM pass with the signature verified for that same domain, DMARC pass at p=none with action=none. No lookalike domain, no cousin spelling, no header forgery to detect, because there was nothing to forge.

ATT&CK files that under valid accounts, T1078. It is account takeover of somebody else's mailbox, used as a delivery asset, and the Japanese business is a victim here rather than a participant. Its domain, its server address and its mailbox stay out of this post.

Six Seals, Three Providers, and a Forward Nobody Reviewed

The envelope recipient was never the insurer. It was a partner organization on a Microsoft 365 tenant, and the headers say so three ways: a Resent-From on the partner's own info address, an X-OriginatorOrg naming the partner's domain, and a pair of Exchange forwarding headers recording the hop out to the insurer's group. What that partnership actually is does not appear in the record, so no relationship is claimed here.

The result is an ARC chain six seals deep across three providers: the Japanese host's business-mail platform at the first instance, Microsoft at the second and third, Google at the fourth, fifth and sixth. Each seal is honest, faithfully attesting what the hop before it observed. Stacked, they carry a compromised mailbox's genuine authentication all the way to an executive.

Here is the sharpest detail in the case. Microsoft had already scored the message as spam inside the partner tenant, SCL:9 at the top of the confidence scale, SFV:SPM, CAT:OSPM. The auto-forward ran anyway. A forwarding rule relays the message and never the verdict, so the insurer's Workspace group accepted delivery from a trusted partner tenant rather than from the open internet, with the spam judgement stripped off in transit.

The group then did what groups do: Mailing-list and List-ID headers, a Google group identifier, X-BeenThere, X-Spam-Checked-In-Group, and a Delivered-To resolving to the Chief Revenue Officer's mailbox. One affected mailbox is recorded, so how far the message travelled inside the list is not established.

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

Two Words and One Link

The payload is insultingly thin. The body is two words, "Fix below", followed by a single link and a 268-character opaque fragment hung off the end of the URL. No stolen thread, no padding, no images, no attachments.

The From field carried a display-name-only impersonation of a well-known communications platform, with a subject line that vendor genuinely uses for outbound sending alerts. Landing on an administrative distribution list, that is a credible thing to receive and an urgent thing to click.

The link hop is supporting colour rather than the point: a Google URL redirector on the Icelandic country-code domain rather than the usual one, forwarding to a numeric-prefixed Azure Front Door host. The wrapper scans clean, the terminal host carries an independent scanner verdict of malicious, and no page capture exists, so what it served is unknown. ATT&CK maps the delivery as spearphishing link, T1566.002, with the display-name trick as masquerading, T1036.005.

What Actually Produced the Verdict

Not the authentication results, which read as a pass on the one signature people trust. Not sender reputation, which had a genuinely authenticating business domain to score. Not the wrapper URL, which scanned clean.

The verdict came from Themis, the Adaptive AI analyst, at confidence 84, on findings across email content, sender analysis and community reputation. Community reputation is the one input that does not depend on infrastructure the operator never owned, and it works because 36,000+ security professionals across 18,000+ organizations have already resolved constructions built this way, per IRONSCALES platform data. The independent malicious verdict on the terminal host and Microsoft's upstream spam score corroborate it. That is scanner and model evidence, not a human adjudication.

It matches where the numbers point. The 2026 Verizon Data Breach Investigations Report puts credentials in 39% of breaches across the full kill chain and phishing at 16% of initial access, with the human element in 62% overall. A working password is the cheapest way to make a phishing email authenticate, a cost the FBI IC3 2024 report has tracked for years.

Stop Reading a DKIM Pass as a Character Reference

Three things fall out, none of them detection projects.

Ask whose key passed. A DKIM pass signed by your own domain, on a message whose header From belongs to an outside domain, tells you the message was imported. It does not tell you the message was trustworthy. Alert on that shape specifically, separately from the list-forwarding noise your own groups generate.

Ask whether anybody owns the failing domain. When the header From belongs to no party in a path you can enumerate, that failure is not a misconfiguration to tune out.

Then audit inbound auto-forwards from partner tenants and the posting policy on the groups they land in. CISA's phishing guidance and the NIST definition of phishing both put the lure at the center of the control problem. This lure got its credibility entirely from plumbing two organizations configured on purpose.

Indicators of Compromise

MITRE ATT&CK Mapping