A downstream DMARC pass does not establish that the person who initiated a message was authorized to use its visible sender. The December 2025 LaunDroMARC research from Engage Security describes an indirect route in which remailing changes the identity evaluated by SPF. Understand the individual hops before describing the finding as a universal DMARC bypass or assuming that every Microsoft tenant behaves the same way today.
Separate the two evidence sources
The original researcher describes an incoming message that passed SPF for its own envelope domain but failed DMARC against the imitated visible From domain. In the reported case, a Microsoft 365 forwarding path rewrote the envelope into the forwarding domain, which also matched the visible From domain. The final receiver then observed aligned SPF. The researchers report different treatment of the original and forwarded copies. These are attributed findings from their investigation, not observations made for this review. Engage Security research.
Microsoft's documentation explains that SRS changes MAIL FROM, not the visible From field, and gives rewriting patterns for applicable forwarding routes. It also warns that SRS normally does not solve DMARC alignment for forwarded mail. Those statements are compatible with the research's special identity coincidence: ordinarily the original From domain differs from the forwarder's domain; the reported case deliberately involves the same domain. Microsoft SRS documentation.
Understand the downstream verdict
References: RFC 9989 §4.4, RFC 8601 §5.
SPF asks whether the connecting host is authorized for the envelope identity at that hop. DMARC compares an authenticated domain with the visible From domain. Neither result, standing alone, reconstructs how the original actor obtained access to a forwarding workflow. A downstream aligned result can therefore be correct for the evaluated identities while still being inadequate evidence of business authorization.
Do not interpret an SRS-looking Return-Path as proof that Microsoft produced it. Preserve the final receiver's trusted results, peer information and message trace, and compare evidence from the receiving and forwarding boundaries. Arbitrary embedded Authentication-Results text is not a trusted verdict. RFC 8601 explains the trust-boundary requirement; RFC 9989 supplies the domain-alignment context.
Reproduce only the identity comparison
The private review package’s non-delivery model contains two fictional cases. In the normal case, the original visible author.test domain differs from the rewritten forwarder.test envelope, so assumed downstream SPF pass remains unaligned. In the second case, the visible domain is forwarder.test; the same rewritten envelope now aligns. Both begin with a different original envelope domain and no aligned DKIM.
The retained fixture inputs were recomputed offline on 8 November 2026 using this exact-domain comparison. It does not send spoofed mail, create forwarding rules, exercise Exchange Online, implement SRS hashes or prove that a current tenant accepts the route. Its purpose is to explain why the two verdicts differ without reproducing an attack against a real service. Historical vendor behavior, current tenant behavior and the abstract comparison remain separately labelled.
Investigate defensively
Inventory authorized external forwarding and its business owners. For a suspected incident, preserve the original and forwarded copies, timestamps, routing method, pre-forward authentication and final results. Review the provider's current documentation and message tracing before changing a rule. The Microsoft source distinguishes applicable forwarding from relay-pool and on-premises cases, so a single configuration claim is not enough to cover every path.
Apply changes through the organization's approved mail-security process and test legitimate workflows afterward. Avoid broad allow rules based solely on provider infrastructure or downstream pass results. This article establishes the mechanism and investigation questions. It does not assert an unverified remediation date, universal exposure, successful exploitation or a current Microsoft service defect.