Kiran 
A single blank field in an email’s technical header is enough to defeat Microsoft 365’s dedicated anti-spoofing control, according to new research from ReliaQuest’s Threat Research team.
The flaw isn’t a coding bug in Microsoft’s software; it’s a scope gap in RejectDirectSend, the Exchange Online setting designed to stop unauthenticated Direct Send emails from impersonating internal users.
Direct Send lets devices such as printers, scanners, and line-of-business applications email recipients within the same Microsoft 365 tenant without requiring a login.
Empty SMTP Field Bypasses Microsoft 365’s
It’s a convenience feature, but one attackers have long abused to spoof internal addresses. RejectDirectSend was rolled out specifically to close that gap by checking the domain listed in the SMTP envelope sender field and blocking messages that fail the check.
The problem, ReliaQuest found, is that the control only knows what to do when a domain is actually present.
Strip the envelope sender down to nothing a technically valid, standards-compliant configuration known as a null reverse path and there’s no domain left to evaluate. The message sails through.
Researchers Tristano Di Liberto and Austin Ritchie confirmed the behavior on a controlled, ReliaQuest-owned tenant with RejectDirectSend already switched on.
Using a short Python script built on the standard smtplib library, they sent two nearly identical unauthenticated test emails, both spoofing an internal “IT Support” address differing only in the envelope sender field.
The baseline message, sent with an envelope address from the tenant’s own domain, was rejected outright with a “Direct Send not allowed” error.
The second message, sent with MAIL FROM:<>, was accepted and queued for delivery, still displaying the same trusted-looking internal address to the recipient. No stolen credentials, no lookalike domain, and no attacker-controlled sending infrastructure were needed.
Notably, the bypass message during testing landed in Junk Email rather than the inbox, and was flagged with a maximum Spam Confidence Level of 9 after failing SPF, DKIM, and DMARC checks.
But ReliaQuest cautions that this is a downstream filtering outcome, not proof RejectDirectSend worked; the message had already slipped past the control before spam filters made their call.
Because that verdict depends on sending infrastructure and content quality, a better-crafted message could reach the inbox directly.
One control did hold up consistently: IP-restricted inbound connectors, which check the source IP rather than the envelope sender, blocked every Direct Send attempt in testing regardless of the bypass.
ReliaQuest says it has tracked this empty-envelope pattern in live phishing cases across multiple organizations between September 2025 and August 2026, with a concentration on executives, managers, and finance or procurement staff.
File-sharing notifications and payment or remittance requests were the most common lures, with some campaigns using SVG attachments disguised as voicemail messages.
In several incidents, spoofed executive addresses had been whitelisted, allowing high-confidence phishing verdicts to pass through anyway.
Mitigation
ReliaQuest advises organizations to:
- Deploy IP-restricted inbound connectors limiting Direct Send to approved, inventoried devices.
- Audit and prune filtering exceptions, safe-sender lists, and Tenant Allow/Block entries, especially those covering executives.
- Hunt for messages combining an empty envelope sender with an internal-domain “From” address that also failed SPF, DKIM, or DMARC.
Microsoft has been notified of the gap multiple times, but since it’s classified as a control-scope limitation rather than a vulnerability, organizations shouldn’t expect a patch; layered defenses remain the only mitigation for now.
Site: Thecyberdef.com
Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.
About the Author
