LaunDroMARC
Microsoft email forwarding vulnerability. Laundering malicious mail.
Washing dirty mail since 2023
Background
Engage Security researcher Aaron Hart was investigating a potential business email compromise.
At first it looked like a classic phishing attack; recipient receives a polished looking email supposedly from a reputable sender, recipient clicks a link in the email, is presented with a login page, enters credentials, accepts MFA prompt and then it’s game over for that person’s O365 account.
After reviewing the malicious email and talking to the recipient, Aaron realised this attack was different.
The sender appeared to be from a trusted domain, an organisation the recipient also worked for (we will call it ORG 1)
The message recipient (TO) field was the recipient’s address in ORG 1, but delivered to their inbox in ORG 2
The message passed all foundational mail security checks (SPF and DMARC) made by ORG 2 against ORG 1
The message Return-Path address indicated SRS forwarding was being used from ORG 1
The email arrived in ORG 1 from the attacker’s domain (original sender), passing SPF but failing DMARC
How could an original message that failed DMARC get successfully forwarded then pass DMARC on the forwarded hop?
As mailbox providers clamp down on emails that violate domain mail security controls like SPF, DKIM and DMARC some legitimate emails invariably get caught up in the net and don’t make it into the recipient’s inbox. Automatically forwarded emails are especially hard hit because of the way SPF works, and the way email forwarding generally works (sender address is not rewritten when forwarded).
Sender Rewriting Scheme (SRS) was introduced by Microsoft in 2023 to improve deliverability of mail that is automatically forwarded from a Microsoft Exchange Online account to an email address external to that account.
Unfortunately, as Aaron discovered, in attempting to resolve one problem, email deliverability for forwarded mail, Microsoft is inadvertently laundering forwarded malicious email. They are enabling this is by not checking if the original email is spoofing an email address in the forwarding domain.
Note, this is not a misconfiguration or failure on behalf of the forwarding tenant. Forwarding and SRS rewriting is happening before tenant email security controls are applied. If your tenant is forwarding email (and it will be) then your tenant is potentially laundering malicious emails.
This is having real-world consequences and resulting in successful phishing attacks. When the sender seems to be from a trusted domain and or sender, the recipient’s guard is down.
Mail Security Basic Primer
Bear with us, it’s primer time. If you already understand how SMTP, SPF, DKIM and DMARC work, skip ahead. Otherwise, here’s a very high-level overview, it’s important to understand how we got here!
Simple Mail Transfer Protocol (SMTP) is one of the oldest in-use protocols on the Internet. While it has had refinements over the years, it hasn’t changed much since RFC821 was introduced back in 1982. SMTP is a text-based protocol, with all critical elements of an email consisting of text strings and newline characters (CRLF).
SMTP is awesome in its ubiquity. Many flashier protocols have come (and some gone) but SMTP keeps trucking. Like it or loathe it, it is still critical to the running of many organisations and it won’t be going away soon.
SMTP is also widely abused, this fact needs no introduction in 2025.
Two of the most important concepts to understand about email security are the MAIL FROM and FROM text headers.
MAIL FROM is also known as the Envelope From header, think of this as the from address written on the back of a letter envelope (hopefully you’ve seen one of those!). The MAIL FROM is never exposed to the email recipient, it is part of the SMTP transaction between mail transport systems.
FROM is the header that you see in your inbox. Think of it like the from address in a formal letter (if you’ve ever seen one) where the sender’s details are at the top of the letter itself. It is part of the mail content.
Effectively the mail system uses the Envelope Headers to direct the email to your mailbox, then the email client (including web clients) only shows you the actual mail content, not any of the details on the envelope.
In the (not so) bad old days of problematic email SPAM back in the early 2000’s a security protocol was introduced called Sender Policy Framework (SPF). SPF allows orgs to add an entry to their domain’s public DNS records that enables mail-receiving systems to check to make sure the mail-sending system is allowed to send email for the domain in the email MAIL FROM address (everything to the right of the @). This was designed to stem the tide of email where scammers simply sent email saying it was from alice@engagesecurity.nz, when it absolutely wasn’t (called, spoofing the MAIL FROM)!
SPF was great! Orgs could start quarantining or dropping mail that was spoofing the MAIL FROM and for a little while unwanted and malicious email deliveries plummeted.
But the baddies took another look at SMTP and thought, why don’t we just set up our own SPF records for (say) dodgytemporarydomain.com and in the MAIL FROM header say we’re alice@dodgytemporarydomain.com but in the FROM header (the one the recipient sees) say we’re alice@engagesecurity.nz.
SPF passes, and the dodgy email ends up in the recipient’s inbox looking like it came from engagesecurity.nz. “D’oh” said the world, “we didn’t think about that”.
SPF also has weaknesses with forwarded mail, which is important in the context of this vulnerability, so we’ll talk about it briefly.
When a recipient sets up automated email forwarding, the original MAIL FROM domain is kept as-is by the forwarding mail system As that system is on the recipient’s side of the SMTP exchange, it is seldom in the SPF allow list. This causes the forwarded email to get dropped or quarantined at the ultimate forwarded destination.
An email security standard was introduced called Domain Keys Identified Mail (DKIM), which was designed to overcome the forwarding problem. During sending, the headers in the email content, including the FROM address, are digitally signed. Recipient systems could ignore SPF failures, validate the signature of the content headers and everything was peachy. Well, no, DKIM suffered from the same shortcomings as SPF, attackers could just sign headers themselves, so mail spoofing was still possible. “D’oh” said the world again.
To work around the FROM header spoofing shortcomings of both SPF and DKIM, a new mail security standard was created called Domain-based Message Authentication, Reporting & Conformance (DMARC). DMARC builds on SPF and DKIM, it doesn’t replace them (if an email fails SPF it will get dropped early in the SMTP process). DMARC does a couple of clever things, one of them being, it allows sender domains to instruct recipients systems to reject, quarantine or report email where the MAIL FROM and FROM headers don’t align or the DKIM signing domain and FROM headers don’t align. Why was this not done earlier? Well, hindsight is a wonderful thing.
So we ended up with a pretty robust system. DMARC has had a massive impact on FROM spoofing (aka domain spoofing). Attackers continue to try sneaky things like registering look-alike domains, but DMARC is still the workhorse of mail security, removing a huge percentage of dodgy mail and allowing more advanced mail security technology to work on the tougher problems.
SRS to the Rescue?
This is why LaunDroMARC is such a disappointing vulnerability. It throws out the advantages of the DMARC standard, launders spoofed malicious email and has resulted in at least one account compromise that we are aware of (this means likely many more).
There are many scenarios where emails are forwarded from one account/provider to another: consultants, contractors, board members, support staff, interest-group mail lists, cross company collaboration groups etc.
The vulnerability exists in Microsoft’s implementation of SRS.
SRS is used in all likely mail forwarding scenarios and has been enabled in all Exchange Online tenants since 2023 (yes that means yours too).
SRS will rewrite the MAIL FROM domain for messages that pass SPF checks. Remember that passing SPF is a very low bar. Attackers have been doing that for decades; they just need to use a MAIL FROM domain that they own and send from an IP address specified in their own SPF DNS record.
SRS will then rewrite the MAIL FROM address to match the forwarding domain, the legitimate Exchange Online authoritative domain.
Big deal you say? We still have DMARC to fall back on right? Microsoft wouldn’t allow us to spoof the FROM header to match the forwarding domain, allowing us to get them to configure DMARC header alignment once the SRS MAIL FROM rewrite happens, right?
If Microsoft detects an external party is spoofing a FROM header that belongs to the receiving domain they would just reject the mail and never forward it on, right? Right?
Wrong. That is exactly what happens as of December 1st, 2025.
Vulnerability
Consider the following (synthetic) scenario:
Attacker owns the domain dodgyattacker.nz
They have an SPF TXT record for that domain that allows 203.0.113.113 to send email
Bob has an Exchange Online mailbox in goodsortsincorporated.nz
Bob is a consultant and has all his email forwarded to his account at clickingonthings.nz
Good Sorts Incorporated admins have been good, they have a DMARC reject policy for goodsortsincorporated.nz
Attacker crafts an email with the following headers set:
MAIL FROM: alice@dodgyattacker.nz
RCPT TO: bob@goodsortsincorporated.nz
FROM: Alice Theboss <alice@goodsortsincorporated.nz>
The attacker sends the email from 203.0.113.113
This will pass SPF
When the email arrives at Good Sorts Incorporated, Exchange Online helpfully:
Ignores any sending domain DMARC failure, if any (or doesn’t get to processing it, more on that in the future)
Rewrites the MAIL FROM header to: bob+SRS=XXXX=XX=dodgyattacker.nz=alice@goodsortsincorporated.nz
Voila, DMARC header alignment
Forwards the newly aligned mail to bob@clickingonthings.nz
Quarantines the original (non-forwarded) message if it failed DMARC from the sending domain (this means the non-aligned email is never seen by the recipient)
The forwarded copy of the email arrives at Bob’s inbox at clickingonthings.nz
DMARC passes and mail is delivered.
Bob opens the email in his clickingonthings.nz mailbox and can see it was sent to his goodsortsincorporated.nz address from alice@goodsortsincorporated.nz - that looks legit!
Bob starts clicking links or calling numbers in the email and logging into things
We successfully tested this across multiple unassociated Exchange Online tenants. Mail was delivered reliably.
Congratulations SRS, you’ve laundered a malicious email and broken DMARC.
Responsible Disclosure
In the interests of responsible disclosure, we submitted a bug report to Microsoft, but despite the fact this has been abused in the real world for credential compromise, were told this was a low risk and would not be fixed.
We gave Microsoft an additional 21 days to accept that this was a risk, no result. Now we are sharing it with you so you can be aware of the problem and initiate steps to detect and remediate.
Resolution
Microsoft could solve this vulnerability by:
Not SRS rewriting MAIL FROM headers where the message was sent from an external domain but the FROM header is an accepted domain in the receiving/SRS-forwarding tenant
This one should be the most obvious.
On the ultimate receiving domain, compare the Authentication-Results + Authentication-Results-Original mail headers, if there are signs of spoofing the original (forwarding) recipient, quarantine the email.
Only SRS rewrite mail that has a DMARC pass (i.e. not a Fail, None or null result)
In our testing, sending from origin domains that have DMARC reject policies, FROM header spoofing (causing DMARC reject) had no effect on the successful rewriting and forwarding of malicious mail. Interesting.
Detection
Detection is different depending on if you have visibility over the forwarding tenant, or the receiving tenant (the receiving domain may not even be Exchange Online, could be anything).
Forwarding Domain
To detect possible forwarding vulnerability abuse you can use the following query in Defender XDR Advanced Hunting
// First get all your primary email domains
let OurEmailDomains = IdentityInfo
| where
Type == 'User' and
AccountUpn !has "#EXT#" and
isnotempty(EmailAddress)
| extend EmailDomain = tostring(split(EmailAddress,'@')[1])
| distinct EmailDomain;
// Now get inbound messages that are spoofed, note some may be legitimate spoofs
let InboundSpoofedMail = EmailEvents
| where
EmailDirection == 'Inbound' and
SenderMailFromDomain !in (OurEmailDomains) and
SenderFromDomain in (OurEmailDomains)
| extend AuthenticationDetails = parse_json(AuthenticationDetails)
| extend SPFResult = AuthenticationDetails.SPF,
DMARCResult = AuthenticationDetails.DMARC
| where SPFResult == 'pass' and DMARCResult in ('fail',"none")
| distinct NetworkMessageId;
// Now return messages with spoofed FROM headers that also got forwarded externally
EmailEvents
| where
NetworkMessageId in (InboundSpoofedMail) and
EmailDirection == 'Outbound'
Recipient Domain
If the recipient domain uses Exchange Online and Defender XDR, it is easy to see emails received that have been forwarded with SRS. And it is easy to extract the original sending domain in the MAIL FROM header surfaced in Advanced Hunt. If you get MAIL FROM and FROM header alignment, but the original sending domain doesn’t match either FROM header, you likely have a spoofed email.
EmailEvents // The email has been SRS forwarded from an external tenant | where SenderMailFromAddress has '+srs=' // Get the original sending domain from the SRS rewritten MAIL FROM - SenderMailFromAddress | extend OriginalSenderMailFromDomain = tostring(split(SenderMailFromAddress,'=')[3]) // If there is MAIL FROM and FROM header alignment, but the original MAIL FROM is different, this could be a spoofed forwarded/laundered mail | where SenderFromDomain has SenderMailFromDomain and SenderFromDomain != OriginalSenderMailFromDomain
Primary researcher and bug discoverer: Aaron Hart
Secondary researcher and report wrangler: Philip May
No generative AI was used in the writing of this report. We want to understand these problems, and we want you to understand these problems too. We respect your time too much to waste it on gen slop. Look, gen AI has its uses but, horses for courses people.