Microsoft built RejectDirectSend to close a specific hole: unauthenticated mail claiming to come from inside an organization’s own domain. Researchers at ReliaQuest found that the control can be walked around entirely by leaving one SMTP field empty. No stolen credentials. No software vulnerability in the traditional sense. Just a message sent with nothing in the envelope sender at all.
What RejectDirectSend Was Supposed to Fix
Direct Send is the Microsoft 365 feature that lets printers, scanners, line-of-business applications, and other devices relay mail through a tenant’s own infrastructure without authenticating first. It is convenient, and it has also been a well-documented spoofing vector: an external attacker who finds a tenant’s predictable send endpoint can submit mail that looks internally generated. Microsoft’s answer was RejectDirectSend, a setting that blocks unauthenticated Direct Send messages when the domain in the SMTP envelope sender matches a domain the organization owns.
That description contains the gap. RejectDirectSend checks a domain. It never accounts for what happens when there is no domain to check.
The Bypass: MAIL FROM With Nothing After It
Every SMTP transaction carries two sender identities. The one recipients see is the visible From header. The one mail servers use for routing and authentication is the envelope sender, set by the MAIL FROM command during the SMTP conversation. A message can legitimately be sent with an empty envelope sender, written as MAIL FROM:<>, a null reverse path most commonly used for bounce messages so they cannot themselves generate further bounces.
ReliaQuest found attackers repurposing that legitimate mechanism. Send a message with MAIL FROM:<>, an empty envelope sender, while the visible From header still displays a spoofed internal address, and RejectDirectSend has nothing to evaluate. The control is written to compare a domain against a list of accepted domains. An empty field is not a domain that fails the comparison. It is the absence of a comparison. Microsoft’s own Direct Send documentation describes the setting as applying when the envelope-sender domain is an accepted domain; it says nothing about what happens when that field is blank, because the control was never built with that case in mind.
What the Authentication Headers Actually Show
This is not a message that quietly slips past authentication unnoticed. SPF and DKIM come back with no result, since there is no envelope-sender domain for SPF to evaluate in the first place, and DMARC fails outright. On paper, every signal a defender would want is present and pointing at phishing. In one case ReliaQuest documented, a message failed every sender authentication check and was still classified as high-confidence phishing by downstream filtering, yet it reached the inbox anyway, because the spoofed executive address happened to be sitting on an allowed-sender list. RejectDirectSend had already let the message into the tenant’s mail flow before any of that scoring occurred. The authentication failure was real, logged, and correct. It simply arrived after the decision that mattered had already been made.
Who Is Actually Getting Targeted
ReliaQuest reviewed cases from September 2025 through August 2026 and found a clear pattern in who receives these empty-envelope messages. Forty percent went to senior leaders. Twenty-five percent went to managers and sales staff. Twenty percent reached individual contributors, and the remaining fifteen percent landed in shared or service account mailboxes. The lures leaned toward business process, not urgency theater: file-sharing notices were the single most common template, followed by payment and remittance requests, procurement invitations, loan or investment offers, and meeting invitations. None of these need a panicked click. They need one ordinary business interaction to feel plausible, from an address that looks like it belongs inside the building.
Why This Sits Squarely in DMARC’s Blind Spot, Not Outside It
Most of the campaigns worth writing about pass DMARC cleanly and leave the protocol with nothing to say. This one is different, and more uncomfortable, because DMARC does say something here. It fails, correctly, exactly as designed. The gap is not in what DMARC evaluates. It is in a downstream control that was supposed to enforce a consequence for that failure and instead never got invoked, because it was built to check a field that attackers learned they could simply leave empty. A strict DMARC policy protects a domain from being spoofed on the open internet. It does very little for a tenant-side control with its own separate, narrower definition of what counts as a domain worth checking.
What This Means for Your Program
Do not assume a named anti-spoofing control covers every input to that spoofing vector. RejectDirectSend does real work against the Direct Send abuse it was designed for. It was not designed against an empty envelope sender, and controls with narrow, specific logic tend to have exactly this kind of edge case sitting just outside their scope.
Audit your allowed-sender and safe-sender lists for executive and finance addresses. The case that reached the inbox here did so because a spoofed internal address was already on an allow list. A list built to reduce false positives for legitimate internal senders is also, silently, a bypass for anyone who successfully spoofs those same addresses.
Alert on the combination, not just the failure. A message with SPF returning no result, DKIM absent, and DMARC failing, arriving with a display name matching an executive, is a specific and detectable pattern regardless of which delivery mechanism let it through. Build the rule around that combination rather than trusting any single upstream control to have already caught it.
Ask your vendor, and Microsoft, how RejectDirectSend behaves on a null envelope sender today. This is the kind of gap that gets patched once it is public. Confirm your tenant’s current behavior rather than assuming last quarter’s mitigation still holds.
The Takeaway
RejectDirectSend was a genuine fix for a real spoofing problem, and it still is, for the specific case it was built to check. What ReliaQuest documented is not a failure of DMARC. It is a reminder that the controls organizations layer on top of DMARC to enforce its verdicts can carry their own gaps, gaps that a strict DMARC policy has no visibility into and no ability to close. The message failed authentication exactly as it should have. Something else was supposed to act on that failure, and one blank field was enough to make sure it never did.
DMARC told the truth on every message in this campaign. The failure happened one layer downstream, in a control most security teams never think to test against an empty field. Excello Mail gives you continuous, plain-language visibility into your real authentication posture, so gaps like this show up before an attacker finds them first. Sign up for free to Excello Mail and see your actual authentication picture today.