When a DMARC Reject Policy Trusts Its Own Domain

The memo looked like housekeeping. The sender was listed as "Office Admin," the address behind that name belonged to the recipients' own organization, and the subject demanded attention in the clipped, all-business tone that internal IT notices tend to use. It reached four mailboxes at a regional community health organization at the same time. There was no visible link and no body text worth reading. The entire message was a subject line and a single file attached to an empty page. What makes this case worth studying is not the lure. It is that the message should never have been delivered at all, and the reason it was delivered is a trust assumption most organizations never think to question.

The organization published a Domain-based Message Authentication, Reporting and Conformance (DMARC) policy on its own domain set to reject. That is the strongest enforcement posture available, an instruction to receiving mail systems to refuse any message that claims to be from the domain but cannot prove it. This message could not prove it. And it was delivered anyway.

The Authentication Was an Unambiguous Failure

There was no ambiguity in the headers. Sender Policy Framework (SPF) returned a softfail, because the connecting server was not authorized to send for the organization's domain. DomainKeys Identified Mail (DKIM) was absent entirely; the message carried no signature to verify. DMARC failed, and the policy action recorded was reject. Microsoft's composite authentication result was compauth=none with reason code 451, the code that marks a message as failing implicit authentication and spoofed. Every technical signal that exists to stop domain impersonation pointed the same direction.

The message originated from 51.89.81[.]166, whose reverse DNS record resolved to ip166.ip-51-89-81[.]eu, an OVH-hosted virtual private server with no relationship to the organization's actual mail gateway or to any recognized enterprise sending infrastructure. This was not a compromised internal mailbox sending from inside the tenant. It was an unrelated rented server on the public internet, presenting itself as an employee. The specification that defines exactly how a reject policy is supposed to handle this, RFC 7489, is the same specification the organization had already implemented. The rule was in place. It simply did not get the final word.

The Trust Override That Beat the Policy

Despite the stack of failures, Microsoft assigned the message a spam confidence level of negative one, the score reserved for mail treated as effectively risk-free, and routed it to four inboxes. A negative-one score on a message that fails SPF, carries no DKIM, and fails DMARC under a reject policy is not a scanning mistake. It is the fingerprint of an internal-domain trust override, a configuration in which messages claiming to come from the organization's own domain are extended a level of confidence that outranks the authentication verdict.

That override is the whole attack. The reject policy told the receiving system to refuse unauthenticated mail from the domain. A separate trust rule told the same system that mail from the domain is safe by definition. Trust won, and the enforcement the organization believed it had turned on was silently negated for exactly the messages it was meant to stop. Self-domain spoofing works precisely because an internal From address inherits trust that a lookalike domain never could. This is the quiet mechanics behind a wide class of business email compromise: the attacker does not need to break authentication when the mail system is configured to forgive its own domain's failures.

An Empty Body Wrapping a Hidden Payload

The delivered message had no meaningful body. The urgency lived entirely in the subject line, a demand that a work email update was required and needed immediate attention. Attached to that empty page was a nested message file, an entire email wrapped as an attachment, weighing a little over fifteen kilobytes and named to resemble a Microsoft service-update notice. The platform's static scanner marked the outer file clean, which is exactly what this wrapper is designed to produce.

A nested email attachment defers the real content one layer past where inline inspection typically reaches. The scanner clears the envelope; the payload waits inside for a recipient to open it. Whatever social-engineering step came next, a credential prompt, a fake login, an instruction to act, was staged behind that file rather than exposed in the message where a gateway could read it. The empty body was not a mistake. It was the point. There was nothing in the visible message for a content filter to catch, and the file that mattered had been packaged to look like routine housekeeping from the recipients' own domain.

Why Behavior Caught What the Gateway Waved Through

The failure here was not in detection. It was in the trust configuration that overrode detection. The authentication headers were unambiguous, and the mail system still delivered. Closing that gap means reading the message the way a human analyst would, weighing the pattern rather than deferring to a single trust rule. An internal memo with an empty body, an urgency-only subject, and a nested attachment disguised as a service update is not how internal communication normally looks, and that deviation from an organization's pattern of life is exactly what Themis, the Adaptive AI analyst on the IRONSCALES platform, is built to surface. It does not ask whether the From address claims to be internal. It asks whether this message behaves like the internal mail this organization actually sends.

Mapping to MITRE ATT&CK

The attachment-borne delivery maps to T1566.001 Spearphishing Attachment, with the nested email file as the wrapped payload. The impersonation of an internal identity on the organization's own domain maps to T1036.005 Masquerading: Match Legitimate Name or Location, where the sender's apparent legitimacy comes from matching a trusted name rather than from any technical proof.

Indicators of Compromise

The Takeaway

A DMARC reject policy is only as strong as the trust rules sitting beside it. Publishing enforcement and then configuring the mail system to forgive its own domain leaves an unmonitored back door precisely where organizations feel safest. The 2024 Verizon Data Breach Investigations Report puts the human element in more than two-thirds of breaches and names pretexting, the category that covers most business email compromise, as the leading social-engineering type. Attacks like this one exploit the moment an organization decides its own domain deserves the benefit of the doubt.

Audit what your mail system does with messages from your own domain that fail authentication. Confirm that a reject policy actually rejects rather than being overridden by an internal allow-list or a favorable spam score. Treat nested email attachments as a payload to inspect, not a wrapper to clear. And pair that discipline with detection that weighs behavior over a claimed identity.

Curious how much of this your current gateway waves through? Measure the gap.

See You Next Time

The hardest attacks to stop are not the ones that break the rules. They are the ones the rules were quietly told to ignore.