PowerDMARC

LaunDroMARC: How a Microsoft SRS Loophole Is Laundering Spoofed Emails

Ahona Rudra
LaunDroMARC

Key Takeaways

  • Email forwarding can inadvertently bypass DMARC protections.
  • Microsoft’s SRS can “launder” malicious emails, making them appear trusted.
  • LaunDroMARC affects both internal and external forwarded messages.
  • Continuous monitoring and visibility are crucial for email security.
  • PowerDMARC provides tools to detect and mitigate such forwarding loopholes.

Security researcher Aaron Hart was investigating what looked like a regular business email compromise attempt. But the deeper he looked, the stranger it became. Everything about the attack appeared polished and believable: the sender domain, the authentication results, and the path the email took.

Yet something impossible had happened. An email that failed DMARC at the source was magically passing DMARC after being forwarded through Microsoft Exchange Online.

This shouldn’t be possible. But it was – and it was happening because of a side-effect of Microsoft’s Sender Rewriting Scheme (SRS) implementation.

This blog breaks down the issue in simple language, originally shared by Engage Security, explaining how the loophole works and how organizations can detect and mitigate the risk.

How Microsoft SRS Causes DMARC Bypass 

During the investigation, Aaron noticed:

In short: A spoofed email that should have been rejected got forwarded, rewritten, and “washed clean”, then delivered as a trusted message. This resulted in a real-world account compromise, and it wasn’t a one-off.

Why This Matters

Email forwarding is extremely common across organizations:

Since 2023, Microsoft has enabled SRS for all Exchange Online tenants, intending to fix SPF failures caused by email forwarding. Unfortunately, this fix created a new problem: forwarded malicious emails now appear fully authenticated, even when they originally failed DMARC.

This phenomenon has now been dubbed “LaunDroMARC” because the forwarding process literally “launders” malicious messages.

A Quick Refresher: SMTP, SPF, DKIM & DMARC

MAIL FROM vs FROM

SPF

Sender Policy Framework verifies whether the sending server is allowed to send mail for the MAIL FROM domain. SPF does not validate the visible FROM address and breaks on forwarding (forwarders aren’t in the sender’s SPF record).

DKIM

DomainKeys Identified Mail digitally signs email headers, including the FROM. Attackers can potentially DKIM-sign their own malicious domains, highlighting one of the weaknesses of the protocol.

DMARC

Domain-based Message Authentication, Reporting, and Conformance fixes alignment problems by requiring MAIL FROM domain to match the FROM domain, or the DKIM signing domain to match the FROM domain, in order to pass authentication. If alignment fails, the domain’s DMARC policy tells receivers whether to deliver, quarantine, or reject the message. 

DMARC significantly reduced spoofing until this loophole reintroduced it.

Where Things Broke: Microsoft’s SRS Implementation

SRS was introduced to prevent SPF failures during forwarding. But Microsoft’s implementation has a critical gap:

Microsoft rewrites the MAIL FROM even when:

Once rewritten using SRS, the MAIL FROM now aligns with the FROM domain, making DMARC pass at the final destination.

The outcome: a malicious email that should normally fail DMARC ends up being forwarded, rewritten by SRS, and perfectly aligned with the forwarding domain’s authentication records. As a result, it’s delivered to the recipient as a fully legitimate message. In short, spoofing through email forwarding becomes possible again, undoing the protections DMARC was designed to provide.

Microsoft currently does not treat this as a security vulnerability.

Example Scenario

Imagine an attacker controlling the domain maliciousmailer.com, with SPF records configured to allow sending from IP 198.51.100.25. They craft an email intended for a consultant, Sarah, whose work email is sarah@company.com but is automatically forwarded to her personal mailbox at sarah@personalmail.com.

The attacker sets the email headers as follows:

When sent, SPF validation passes because the MAIL FROM domain is controlled by the attacker. When the email reaches company.com, Exchange Online processes it with SRS: it ignores the DMARC failure on the spoofed FROM, rewrites the MAIL FROM to align with the forwarding domain (e.g., sarah+SRS=…@company.com), and forwards it to Sarah’s personal mailbox.

At personalmail.com, DMARC now passes because the rewritten MAIL FROM and the visible FROM are aligned. The email is delivered to Sarah’s inbox looking legitimate, effectively bypassing the protections that should have stopped it.

In short, a spoofed message that should have been blocked is now trusted by the recipient, illustrating how SRS can inadvertently “launder” malicious emails.

Why LaunDroMARC Is Dangerous for Organizations 

This vulnerability is dangerous because users naturally trust emails that appear to come from their own organisation or a familiar internal domain. When malicious emails are forwarded, they bypass the original security checks and arrive looking clean and legitimate. 

Attackers exploit predictable forwarding rules to exploit this blind spot, while security teams often focus on inbound threats rather than on forwarded mail. As a result, this loophole opens the door to serious risks, including sensitive data theft, credential harvesting, internal spear-phishing, and even supply chain impersonation attacks.

What Microsoft Could Fix

There are several straightforward mitigations Microsoft could implement:

  1. Don’t rewrite MAIL FROM via SRS if the FROM header belongs to the forwarding domain but fails DMARC at the initial hop.
  2. Only apply SRS to messages that pass DMARC from the sender.
  3. Compare Authentication-Results headers before and after forwarding.
     If they don’t match, quarantine the message.

How Organizations Can Detect LaunDroMARC

 

1. The Forwarding Domain (Exchange Online)

You can spot potential abuse by looking for emails where the MAIL FROM domain is external, but the FROM header appears to belong to your organisation. These messages often show a pattern of passing SPF while failing DMARC: a red flag in the context of SRS rewriting. When those same messages are later forwarded outbound, it becomes a strong indicator that your forwarding rules are being used to relay spoofed or malicious content.

2. The Final Recipient Domain

If an email shows alignment between the visible FROM address and the rewritten MAIL FROM, but the original MAIL FROM domain buried inside the SRS value doesn’t match either one, it’s a strong indicator that the message has been “laundered” through forwarding and may be a spoofed or malicious email.

PowerDMARC’s Perspective

As a platform dedicated to strengthening global email authentication, issues like LaunDroMARC highlight why monitoring and visibility matter as much as enforcement. Even when standards like DMARC are deployed correctly, implementation gaps at mailbox providers can create vulnerabilities outside your control.

PowerDMARC helps organizations:

Take a free trial or schedule a demo with one of our in-house experts to start protecting your domain today! 

Final Thoughts

The LaunDroMARC issue reopens an attack vector that DMARC was designed to stop, making internal domain spoofing possible again through forwarded mail. While Microsoft currently views this as “low risk,” real-world compromises prove otherwise. 

Organizations relying on Microsoft 365 must be aware of this forwarding loophole and put additional detection measures in place.

Latest posts by Ahona Rudra (see all)
Exit mobile version