Microsoft 365 Groups Bypass DMARC at p=reject: How compauth=none reason=451 Works

In late 2025, while investigating a spoofed phishing email that reached a client's inbox despite an enforced DMARC policy, we discovered a behavior in Microsoft 365's mail handling that materially undermines DMARC for any tenant using Groups. The message had failed SPF. It had no DKIM signature. It therefore failed DMARC. The sender's domain was published at p=reject. By the rules of DMARC, it should have bounced. Microsoft delivered it anyway.

The relevant headers told the story. The DMARC field read dmarc=fail action=oreject. Not reject — oreject. The composite authentication line showed compauth=none reason=451. And no DMARC aggregate report was generated for the failure, because Microsoft routed the message internally rather than treating it as an inbound delivery from the original sender.

This post is a full walk-through of the bypass: how it works, how to verify it on your own tenant, the limits of the original research, and what you can do about it.

The Setup

The message that started this came from an unauthorized external sender, addressed to a Microsoft 365 Group on a customer tenant. The sender had spoofed an unrelated third-party domain that publishes DMARC at p=reject. Microsoft's anti-phishing policy was configured to honor DMARC. The tenant's MX records pointed to a Proofpoint email security gateway, with mail flowing from Proofpoint into Exchange Online via a connector.

By the textbook, every layer should have rejected the message. SPF failed. DKIM was missing. DMARC failed. The sender domain had explicitly told receivers, via DNS, to reject failing mail. And yet the headers showed a successful delivery to the group, with the spoofed From address preserved, and a composite authentication result of none.

What compauth=none reason=451 Actually Means

Microsoft's composite authentication (compauth) is a Defender-side scoring mechanism that combines SPF, DKIM, DMARC, sender history, and a number of internal signals. The reason code explains why compauth arrived at the result it did. There's no comprehensive public list of every reason code, but a few are well-documented in Microsoft's own materials. Reason 109 typically signals failed DMARC with explicit alignment failure. Reason 451 is less straightforward.

In our testing, reason=451 appears specifically when Microsoft has decided the message is being delivered to a "trusted" internal destination — including a Microsoft 365 Group — and is therefore exempting the message from the normal DMARC enforcement path. The composite authentication result of none is the tell: Microsoft has effectively decided not to evaluate authentication at all for the final hop, because the message is being re-injected to group members from within Microsoft's own infrastructure.

The end result is that an external attacker can spoof any domain with p=reject, send the message to a publicly-known Microsoft 365 Group address, and have the message reach every member of the group with the spoofed From address intact. The recipients see what looks like a legitimate email from the spoofed domain. There is no quarantine, no junk routing, and no bounce.

The Reproduction Question

After our published research, dmarcian Director of Professional Services Ash Morin attempted to reproduce the behavior on his own tenant and could not:

"In my tenant, MX points directly to MS, DMARC is at p=reject, and DMARC enforcement is configured to honor that policy. I created an MS365 group, enabled external senders. Sent an email from an unauthorized external VPS IP, spoofing my domain to a regular mailbox, and was rejected as spoof. Sent the same spoofed message to the M365 group → also rejected. Then I spoofed the group itself, and sent to the group and it was also rejected due to DMARC."

This was important context. Ash's tenant had MX records pointing directly to Microsoft. The customer tenant where we observed the bypass had a Proofpoint gateway in front of Exchange Online. The difference matters: when mail arrives at Exchange Online via a gateway connector, certain Defender enforcement paths behave differently than when mail arrives at the tenant's MX directly. The bypass we observed appears to be specific to the gateway-in-front configuration.

This narrows the scope of the finding without eliminating it. A non-trivial percentage of enterprise Microsoft 365 tenants run with a third-party gateway (Proofpoint, Mimecast, IronPort, others) in front of Exchange Online — that's the entire enterprise email security gateway market. For those tenants, the bypass is real and reproducible.

Direct Send: A Parallel Vector

Rob Sobers at Varonis pointed to a related research thread the Varonis Threat Labs team published in 2025: ongoing campaigns abusing Microsoft 365's "Direct Send" feature to deliver phishing without ever needing to compromise an account. The attack pattern: send mail through <tenant>-mail.protection.outlook.com (the tenant's MX) addressed to a recipient on the same tenant, with a spoofed From: address. Microsoft's smart host accepts the connection because the recipient is valid in the tenant. The message reaches the inbox having never been authenticated by Microsoft as inbound external mail.

As Catalin Cucu explained in the same thread: "Direct Send uses a smart host (e.g., company-com.mail.protection.outlook.com) which accepts emails from any source (internal or external). The emails are routed through Microsoft's infrastructure, making them appear as if they originate from within the tenant."

For tenants with MX pointing directly to Microsoft, Direct Send is the immediate concern. For tenants with a gateway in front, the M365 Groups path we documented is the equivalent surface. Both share the same underlying property: once a message is treated as "internal" by Microsoft's mail flow, DMARC enforcement no longer applies the way the sender domain instructed.

What the Headers Reveal

If you suspect this is happening on your tenant, the place to look is the Authentication-Results header on suspect messages. A normal DMARC-failed message that Microsoft honored would show:

Authentication-Results: spf=fail (sender IP is ...) smtp.mailfrom=spoofed.example.com;
 dkim=none (message not signed) header.d=none;
 dmarc=fail action=reject header.from=spoofed.example.com;
 compauth=fail reason=001

A bypassed message — failing the same authentication checks but delivered anyway via the group path — looks like:

Authentication-Results: spf=fail (sender IP is ...) smtp.mailfrom=spoofed.example.com;
 dkim=none (message not signed) header.d=none;
 dmarc=fail action=oreject header.from=spoofed.example.com;
 compauth=none reason=451

The action=oreject is the critical tell. In Microsoft's logging, oreject indicates the message was not, in fact, rejected — it was delivered despite the DMARC failure, with the rejection action overridden by an internal rule. Combined with compauth=none reason=451, this is the fingerprint of the group-path bypass.

The worst operational consequence is downstream: no DMARC aggregate report is generated for these events. The sender domain receives no telemetry that anything failed. Defenders correlate outcomes (a phishing complaint from a user) instead of causes (an authentication failure at the gateway). As one commenter on our research put it, "when telemetry disappears, defenders are left correlating outcomes instead of causes."

Mitigation: Inbound Connector Lockdown

The most reliable mitigation we've found — and the one that finally closed the gap for our affected client — was suggested by Sarkis Kamberian in the comments on our LinkedIn research. It comes from Mimecast's own documentation but applies to any gateway-fronted Microsoft 365 tenant: lock down Exchange Online to accept inbound mail only from your security gateway's IP addresses.

The Mimecast documentation walks through creating a receive connector in Exchange Online that requires inbound mail to come from authorized IPs. Once configured, any mail arriving at the tenant's MX from anywhere other than the gateway is rejected at the connector level — before Microsoft's internal logic ever gets a chance to apply the compauth=none reason=451 exemption.

The same principle applies to Direct Send for tenants with MX pointing directly to Microsoft, although the mitigation there is different — typically a transport rule that rejects inbound mail from external sources where the From address matches the tenant's own domain. Microsoft has documented this pattern under "anti-impersonation policies" in Defender.

For both vectors, the broader pattern is: the tenant operator must explicitly close the trust paths that Microsoft's defaults leave open. Out of the box, neither M365 Groups nor Direct Send enforces DMARC in the way the sender domain requested. The administrator has to actively configure the tenant to do so.

What This Means for DMARC

DMARC at p=reject materially reduces spoofing risk. It's not a placebo, and we still recommend every domain reach p=reject as the endpoint of an enforcement program. But the protection is asymmetric. It protects strongly against spoofing aimed at well-configured receivers, and weakly against spoofing aimed at receivers whose internal mail handling overrides the policy.

That asymmetry is one of the reasons we keep saying — and have said in published work elsewhere — that DMARC is a policy request, not a technical enforcement mechanism. The sender domain instructs receivers what to do with failing mail. Receiver compliance is voluntary, both in the literal sense (some receivers, like So-Net in Japan, don't honor DMARC at all) and in the structural sense (some receivers honor DMARC for inbound external mail but exempt internal mail paths). Microsoft falls into the second category for Groups and Direct Send.

If you operate a Microsoft 365 tenant — particularly one with a security gateway in front — assume that DMARC bypasses exist in your environment until you've explicitly closed them. Audit your inbound connectors. Verify your anti-phishing policy honors DMARC at the policy level (Defender → Threat policies → Anti-phishing → Actions → "Quarantine when DMARC publishes p=quarantine" / "Reject when DMARC publishes p=reject"). And lock down inbound mail flow so that mail arriving outside your authorized path is rejected, not routed through internal logic.

---

Written by the team at SH Consulting. If you operate a Microsoft 365 tenant and want a hardening audit that covers the DMARC bypass paths most teams never check, book a call.