Compromised M365 Mailbox Passes DMARC, Fails SPF

A "scanned document" email landed in an assistant residence manager's inbox carrying what looked like a clean bill of health: a valid DKIM signature, a passing DMARC verdict, and a From address belonging to the chief executive of a real overseas investment firm. Trace the header back exactly one hop and the story collapses. The IP that actually injected the message failed SPF (Sender Policy Framework) and had no reverse DNS record at all.

That split, an authenticated pass at the delivery boundary sitting on top of an unauthenticated true origin, is the cleanest fingerprint of account takeover (ATO) you will find in a mail header. The sending domain was not attacker-registered. It belonged to a legitimate business whose mailbox had been hijacked. The investment firm was an incidental victim here too, its executive's account used as a trusted launch pad against a Caribbean residential property-management company.

A CEO mailbox the CEO never touched

The From address was ceo@ a real, established investment-firm domain. No lookalike, no homoglyph, no freshly registered cousin domain. When the sender is genuine, the usual reputation and domain-age heuristics have nothing to grab onto. This is what makes compromised-account phishing so effective: the attacker inherits every bit of trust the legitimate domain has earned.

The tell was not in the domain. It was in the transport. The first Received hop showed origin IP 147[.]124[.]213[.]178, presenting the HELO string "3ef7" with no PTR record and failing SPF outright. That is not a recognized mail gateway. It is someone authenticating directly to the tenant over SMTP submission with stolen credentials, then handing the message to Microsoft 365 to deliver on their behalf. Microsoft's own outbound protection relay accepted it, re-emitted it from 2a01:111:f403:c201::3 (an address inside Microsoft's own SPF-authorized space), and carried the tenant's valid DKIM (DomainKeys Identified Mail) signature forward.

Why the DMARC pass was real and meaningless

Here is the mechanic worth internalizing. DMARC (Domain-based Message Authentication, Reporting and Conformance) passes when either SPF or DKIM aligns with the visible From domain. The true origin failed SPF, but the DKIM signature was genuinely valid, d= the firm's own domain, applied by the tenant's own M365 infrastructure. DKIM alignment alone satisfied DMARC.

So the DMARC pass was not forged and it was not a benign forwarding artifact. It was completely real. It just answered a question nobody should have been asking. DMARC alignment at the delivery boundary tells you only that the last relay in the chain, the victim's own Microsoft 365 tenant, is authorized to send for that domain. It says nothing about whether the human or credential behind that relay was legitimate. A hijacked account produces perfect authentication because it is using the real domain's real signing keys.

This is why authentication verdicts alone cannot carry an inbox. Themis, our Adaptive AI, treats the auth stack as one input among many rather than a gate that ends the analysis. The account takeover pattern lives in the contradiction between the hops, and you only see it if something is reading the whole chain instead of the final green checkmark Outlook surfaces.

The scanned-document costume and the empty body

The lure itself was deliberately thin. The body contained nothing but the external-sender caution banner and no links. The payload was a single PDF attachment weighing roughly 482KB (SC_906IKLS91_...pdf, MD5 f5f78901e966057f9183bce4469efbb8), which returned a mixed, partial verdict from static scanning rather than a clean malicious hit.

The subject line used a randomized, opaque token string, the kind multifunction printers (MFPs) generate when they email a scan to a user. This is masquerading by template. A "scanned document" from a known executive reads as routine internal traffic, and the randomized tokens frustrate signature and content-matching filters that key on repeated subject strings. We saw two near-identical incidents hit the same target organization, both using the scanned-document costume, which is consistent with an operator working a target list rather than a one-off.

An empty body with a partially-verdicted PDF from a fully authenticated executive is precisely the message a gateway waves through. IRONSCALES platform data shows secure email gateways (SEGs) miss an average of 67.5 phishing emails per 100 mailboxes each month, and authenticated ATO mail is a large slice of that gap. Themis flagged this one on behavioral and sender-relationship signals, tagged it Suspicious Sender/Message and Incoming Document/Fileshare Phishing, and quarantined it across both affected mailboxes. That is the core of account takeover protection: catching the message the domain's own reputation was vouching for.

Indicators and technique mapping

The behavior maps cleanly to MITRE ATT&CK: T1078.004 Valid Accounts: Cloud Accounts for the compromised M365 mailbox, T1566.001 Spearphishing Attachment for the PDF delivery, and T1036 Masquerading for the scanned-document disguise.

The strategic picture backs this up. The 2024 Verizon Data Breach Investigations Report found stolen credentials involved in 38% of breaches, the top initial action, and the human element present in 68%. The Microsoft Digital Defense Report 2024 documents the same shift toward identity-based intrusion, and CISA's phishing guidance treats credential compromise as a phase-one problem for exactly this reason: once an account is trusted, everything it sends inherits that trust. It is worth remembering that NIST defines phishing around deception rather than infrastructure, which is precisely why an attack sent from a genuine, fully authenticated mailbox still qualifies.

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

Across 35,000+ security professionals in 17,000+ organizations using the platform, the recurring lesson is the same. Authentication tells you about envelopes, not intent.

Trace the first hop, not the last verdict

When a fully authenticated message from a known contact still feels wrong, do not stop at the DMARC verdict your client displays. Walk the Received chain to the earliest hop and check the origin IP for a PTR record and recognizable gateway identity. An SPF failure and a missing reverse DNS record at the true origin, sitting under a clean DKIM and DMARC pass at the boundary, is the signature of a hijacked mailbox, not a forwarding quirk. Detection that reads the whole chain and the sender's behavioral history, rather than the final checkmark, is what closes this gap.