- The Mess: Attackers found a stupidly simple way around Microsoft 365’s
RejectDirectSendprotection: leave the SMTP envelope sender empty. The visibleFrom:address can still impersonate an internal employee, executive or IT department.
Microsoft built RejectDirectSend to stop unauthenticated Direct Send messages that pretend to originate from an organization’s own Microsoft 365 domain.
Direct Send exists for legitimate reasons. Printers, scanners, monitoring systems and legacy applications can use it to deliver mail without authenticating to Exchange Online.
That convenience also creates an attack surface.
Microsoft’s control checks the technical sender carried in the SMTP envelope. ReliaQuest found that when the envelope sender is empty, there is no sender domain for RejectDirectSend to compare against the tenant’s accepted domains.
The message can therefore continue through the mail flow while the visible From: header presents an entirely different identity.
- The Damage: An attacker can send an unauthenticated phishing message that looks like it came from IT Support, an executive or another trusted internal user — without stealing their Microsoft 365 account or registering a lookalike domain.
ReliaQuest reproduced the behavior in a controlled Microsoft 365 tenant.
A message using an envelope sender associated with the organization’s domain was rejected.
The same message, with the envelope sender removed, was accepted and queued.
The visible sender remained unchanged.
That distinction is the entire problem.
The mail server evaluates one identity.
The employee sees another.
Attackers sit in the gap.
The Phishing Campaigns Were Already There
This isn’t just an academic SMTP trick.
ReliaQuest investigated phishing activity involving empty envelope senders between September 2025 and August 2026.
The targets included executives, managers, finance teams, procurement staff and customer-facing employees.
The lures were exactly what you would expect from business email compromise:
- document and file-sharing notifications
- payment and remittance requests
- procurement invitations
- meeting notifications
- investment or loan offers
- voicemail and fax notifications
Some campaigns used SVG attachments disguised as voicemail messages.
The attacker doesn’t need the victim to believe an exotic story.
They need the victim to believe that their own company sent the email.
That is much easier.
RejectDirectSend Didn’t Actually Fail Completely
There is an important catch.
Getting past RejectDirectSend does not mean the message automatically lands in the inbox.
In ReliaQuest’s test, Microsoft 365 still identified the message as anonymous and unauthenticated. SPF and DKIM did not authenticate it, DMARC failed, and the message received a high spam-confidence score before being routed to Junk.
So this is not an “instant inbox takeover.”
It is a transport-control bypass.
And that distinction matters.
Once the message enters the Microsoft 365 mail pipeline, other security controls can still kill it.
The problem appears when administrators have added exceptions, trusted senders, allow rules or other mail-flow configurations that weaken those later defenses.
ReliaQuest found at least one case where a message was classified as high-confidence phishing but still reached an inbox because the spoofed executive identity had been configured as an allowed sender.
That is where a relatively small mail-flow weakness becomes a serious phishing problem.
The Empty Sender Is Normally Legitimate
This is also why Microsoft cannot simply block every message with an empty envelope sender.
MAIL FROM:<> has legitimate uses.
Mail systems use null reverse-path messages for things such as delivery-status notifications and bounce processing.
Blocking them globally could break normal email infrastructure.
So the attacker isn’t exploiting some bizarre undocumented feature.
They are abusing a legitimate SMTP behavior that happens to fall outside the condition checked by RejectDirectSend.
Microsoft’s own documentation describes Direct Send as unauthenticated mail delivered directly to Exchange Online and recommends tighter controls where the feature is not required.
The security lesson is unpleasantly simple:
A control is only as good as the field it actually checks.
The Fix Is Not “Trust the From Address”
Organizations using Microsoft 365 should first determine whether Direct Send is actually required.
If it isn’t, disable or reject it.
If legitimate devices or applications depend on Direct Send, don’t leave the door open to the entire internet.
ReliaQuest recommends using IP-restricted inbound connectors so that unauthenticated Direct Send traffic is accepted only from known, authorized systems.
Administrators should also review mail-flow exceptions and trusted-sender configurations.
An executive address should not magically become trustworthy just because someone added it to an allow list.
Security teams should also monitor for combinations that deserve immediate attention:
empty SMTP envelope + internal-looking From address + failed authentication.
That combination is much more interesting than any one of those indicators alone.
- The Fix: Restrict Direct Send to known sources with IP-restricted inbound connectors, remove unnecessary mail-flow exceptions, and alert on messages with an empty envelope sender paired with an internal
From:address.
The bigger lesson is for Microsoft 365 administrators who believe RejectDirectSend means the problem is solved.
It doesn’t.
It blocks a defined class of unauthenticated Direct Send traffic.
Attackers simply found traffic that falls outside that definition.
Bugstoday Opinion
This is the kind of attack Bugstoday likes.
No zero-day.
No stolen administrator password.
No sophisticated malware.
No nation-state superweapon.
Just an empty SMTP field.
The attacker doesn’t need to forge the entire email infrastructure.
They only need Microsoft 365 to inspect the wrong identity.
And once the message looks like it came from your boss, the security battle moves from servers to humans.
That’s where phishing gets expensive.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
ReliaQuest — Threat Research on Microsoft 365 RejectDirectSend
Microsoft — Exchange Online Direct Send / RejectDirectSend documentation
SC Media — Empty Envelope Email Attacks
Cyber Security News — Microsoft 365 Empty Envelope Sender Technique
GBHackers — Microsoft 365 Direct Send Bypass




