A Spoofed p=reject Domain Landed in Four Inboxes

A regional bank had done the hard part. It published a DMARC policy of p=reject on its own domain, the strictest enforcement setting available, instructing receiving mail servers to discard any message that forged that domain and failed authentication. On paper, nobody should be able to send mail as the bank unless they were the bank. Then a message arrived that claimed to come from an internal colleague on that exact domain, failed every authentication check, and still landed in four internal mailboxes.

The pretext was quiet and internal by design: a compensation adjustment note styled to look like it came from HR. The outer email body was empty. The real content was hidden inside an attachment. And the sender identity was the bank's own domain, turned against the people who worked there.

The self-spoof that should not have worked

The From header aligned perfectly to the domain the bank publishes DMARC for, because the attacker simply forged it. What sat underneath told the real story. SPF failed outright: the message originated from an OVH-hosted IP in France, an address with no authorization to send for the bank and no relationship to the bank's real, gateway-fronted mail path. There was no DKIM signature at all, so there was nothing to cryptographically verify. And with SPF failing and no aligned DKIM to fall back on, DMARC failed under the reject policy, recording an override reject action with a composite authentication result of none.

By every technical measure a filter looks at, this message was condemned. Aligned header, failed authentication, strict policy. The disposition should have been a discard. Instead it was a delivery.

Why a reject policy still had an edge case

This is the uncomfortable part of DMARC that rarely gets discussed. A p=reject policy, defined in the DMARC specification (RFC 7489), is a request to receiving servers, not a physical law. Enforcement lives at the receiving path, and that path can be shaped by allow-list overrides, internal routing quirks, gateway configuration, and the ordering of security controls. When any of those conditions line up the wrong way, a message that should have been rejected can still reach a mailbox.

The lesson is not that DMARC is worthless. It closes the single largest gap in email trust, unauthorized use of your own domain, and every organization should publish and enforce it. The lesson is that a published policy is a control you have to verify end to end, not a guarantee you can assume. Authentication is a foundation. It is not a finish line.

The email hidden inside an email

The attacker did not rely on the spoof alone. The payload was delivered as a message.eml file, a nested message/rfc822 attachment, which is a complete email saved and attached as a file inside another email. It is a deliberate scanner-evasion wrapper. Inline inspection engines parse the outer message, see an empty body and an attached file, and clear it. The lure, the formatting, and any embedded links only surface when a recipient opens the attached message. The platform verdict on the outer file was clean, and the inner content was never independently extracted, which is exactly the blind spot the technique is designed to create.

Pairing a self-domain spoof with a nested wrapper is a two-layer bet. Layer one buys trust: the message looks internal. Layer two buys survival: the content stays invisible until the moment of engagement. An empty-bodied HR message from a colleague, with a document to open, is precisely the kind of low-friction internal request that people action without a second look.

What actually stopped it

Every authentication signal had already failed, and the message had already been delivered, so there was nothing left for a gateway to catch. Detection had to happen after arrival and had to reason about the message rather than its headers alone. This is where our Adaptive AI came in. The system recognized the delivery-path anomaly, an aligned self-domain sender that had comprehensively failed authentication, arriving from infrastructure the bank had never legitimately used, carrying a nested-email wrapper, and it moved to remediate across all four affected mailboxes automatically rather than leaving four employees to spot the forgery on their own.

That distinction matters. The 2024 Verizon Data Breach Investigations Report found the human element present in 68% of breaches, with pretexting, the category that includes business email compromise, ranking as the top social-engineering pattern and a median BEC transaction around $50,000. An internal-looking compensation note is engineered to exploit exactly that human element. Post-delivery, automated remediation removes the message before the reply, the click, or the opened attachment turns a delivery into an incident.

What security teams should take away

Publish and enforce DMARC at p=reject, then verify enforcement on your own receiving path instead of assuming the published policy is honored everywhere. Treat nested message/rfc822 attachments as high-suspicion by default, especially when the outer body is empty. And recognize that authentication-only defenses have a floor: when SPF, DKIM, and DMARC all fail at once and a message still lands, only behavioral analysis of the message itself stands between the lure and the inbox. That gap between what a gateway checks and what actually reaches users is worth measuring directly, which is what our SEG email security gap analysis is built to surface. For internal-pretext fraud specifically, layered business email compromise protection is what turns a failed-auth-but-delivered message into a non-event.

Indicators of compromise

Authentication summary: SPF fail (unauthorized sending IP), DKIM none (unsigned), DMARC fail under p=reject with an override reject action, composite authentication none.

MITRE ATT&CK mapping

• T1036.005 (Masquerading: Match Legitimate Name or Location): forging the organization's own domain in the From header so an external message reads as an internal one.
• T1566.001 (Phishing: Spearphishing Attachment): delivering the lure as a nested email attachment to evade inline content inspection.

See you next time

A reject policy is one of the strongest signals you can send about your own domain, and you should absolutely publish it. Just do not mistake it for a wall. The attacks that reach your people are the ones built to survive the checks you already passed, and those are the ones worth studying next.