Microsoft 365 Can Override DMARC p=reject for Mail Relayed Through Trusted Gateways

Summary
SH Consulting reports that Exchange Online may deliver spoofed mail despite DMARC p=reject when messages arrive through trusted third-party gateways, exposing an oreject/compauth=none reason=451 pattern. It recommends inbound connector lockdown; RejectDirectSend covers只
Key points
- The article reports that a third-party gateway in front of Microsoft 365 can change the receive path: Exchange Online sees an authorized relay rather than the original internet sender.
- The reported header pattern is action=oreject alongside compauth=none reason=451, which the article says indicates that composite authentication was bypassed and the DMARC verdict did not determine delivery.
- Practitioner reproductions described in the article found that Microsoft 365 Groups alone did not trigger the behavior; the third-party gateway was the structural difference in the affected environment.
- The article says these override events do not appear in Microsoft’s DMARC aggregate reports, potentially leaving domain owners without that signal.
- The recommended workaround is an Exchange Online receive connector restricted to the gateway’s IP ranges, with other inbound paths and applications that send mail directly inventoried and handled.
- RejectDirectSend can block unauthenticated Direct Send, but the article cautions that it does not address mail arriving through an authorized third-party gateway connector.
Article Details
- Defense Focus
- Detect and prevent spoofed inbound mail from bypassing DMARC enforcement in Microsoft 365 tenants using third-party email gateways.
- Detection Methods
- Inspect Authentication-Results headers on recent inbound messages for action=oreject together with compauth=none and reason=451.
- Test the spoofing path by sending a message from outside the tenant with a From address using the organization’s domain, then check whether it is rejected or delivered and inspect its headers.
- Inventory inbound connectors in the Exchange admin center and identify any that accept mail outside the primary gateway path.
- Data Sources
- Inbound message Authentication-Results headers
- Exchange Online inbound connector configuration
- MX records
- Rule Types
- Authentication-Results header pattern: action=oreject with compauth=none reason=451
- Platforms
- Microsoft 365
- Exchange Online
- Defensive Actions
- Restrict inbound mail at the Exchange Online receive connector to the third-party gateway’s IP ranges, and configure the default connector to refuse other sources.
- Inventory applications and services that inject mail directly into the tenant before enforcing the connector lockdown; explicitly allow required flows through an appropriate partner connector or redirect them to authenticated SMTP.
- Enable RejectDirectSend with Set-OrganizationConfig -RejectDirectSend $true to block unauthenticated Direct Send attempts, while recognizing that it does not close the trusted third-party gateway relay path.
- Review recent inbound messages for the oreject header pattern and verify that external spoof tests are rejected.
- Ensure every accepted inbound mail flow passes through the intended gateway.
MITRE ATT&CK
People
Aaron H.Provided an explanation of oreject and the role of Spoof Intelligence in the override behavior.Ash MorinReproduced spoof scenarios in a direct-to-Microsoft 365 configuration and identified the third-party gateway as the structural difference in the bypass scenario.Christian SchindlerRan reproductions that helped establish that Microsoft 365 Groups alone were not the cause of the DMARC bypass.Cory LesovskyConfirmed the third-party gateway dependency based on his earlier disclosure to Microsoft.Ivan KovachevContributed analysis of the composite-authentication mechanics and same-tenant trust pattern.Levon VardumyanContributed analysis of the composite-authentication mechanics and same-tenant trust pattern.Sarkis KamberianIdentified the receive-connector lockdown approach described as the workaround for the bypass.
Vendors
Products
Defenderedge. The full filtering stack — SPF, DKIM, DMARC, composite authentication, Spoof Intelligence, Defender — runs against an external connection from an arbitrary sender on the open internet. That's theExchange OnlineMicrosoft's Exchange Online has a result code that doesn't appear in any DMARC RFC: oreject, short for override reject. It means the receiving system saw a p=reject policy, evaluated the message against it, and chose toMicrosoft 365 Apps for EnterpriseHow Microsoft 365 Silently Overrides DMARC p=reject as oreject
