A Microsoft 365 email security-control bypass that lets attackers submit unauthenticated messages posing as internal users by leaving one SMTP field blank.
The technique targets Exchange Online’s RejectDirectSend setting and does not represent a vulnerability in Microsoft software or in ReliaQuest systems; instead, it exposes a limitation in how the control evaluates Direct Send traffic.
Microsoft 365 Direct Send is designed for devices and applications, such as printers, scanners, and line-of-business systems, that need to send mail to recipients within the same tenant without authenticating.
Microsoft introduced RejectDirectSend to reject anonymous Direct Send messages when the SMTP P1, or envelope-sender, domain matches one of the tenant’s accepted domains and the mail did not arrive through a trusted inbound connector.
ReliaQuest found that this protection can be bypassed by using a null reverse path: MAIL FROM:<>.
With no envelope-sender domain supplied, RejectDirectSend has no domain value to compare against the organization’s accepted domains.
An attacker can nevertheless retain a convincing internal-looking address in the visible From: header, such as IT Support <[email protected]>, creating a spearphishing message that appears to originate inside the target organization.
In controlled testing against a ReliaQuest-owned Microsoft 365 tenant where RejectDirectSend was enabled, a message using an accepted-domain envelope sender was rejected with the 550 5.7.68 TenantInboundAttribution error.
A second message, identical except for an empty envelope sender, was accepted and queued for delivery.
Neither test required valid Microsoft 365 credentials, a compromised internal host, a registered lookalike domain, or dedicated attacker-controlled sending infrastructure.
The bypass should not be confused with guaranteed inbox delivery. In ReliaQuest’s test, Exchange Online identified the accepted message as anonymous and unauthenticated.
Recorded SPF and DKIM failures, applied DMARC fail, and assigned the message the maximum Spam Confidence Level of 9 before routing it to Junk Email.
However, acceptance by the transport service occurs before later antispam and mailbox-placement decisions. A message can therefore bypass RejectDirectSend even if downstream defenses subsequently quarantine it or place it in Junk.
Microsoft 365 Security Bypass
That distinction becomes important where organizations have configured broad mail-flow exceptions.
ReliaQuest investigated multiple cases, from September 2025 through August 2026 involving messages with empty envelope senders, often sent to executives, managers, finance teams, procurement personnel, and customer-facing business roles.
The observed lures included file-sharing notices, payment and remittance requests, procurement invitations, investment offers, meeting notices, and voicemail-themed SVG attachments.
In at least one case, a message that failed sender authentication checks and was classified as high-confidence phishing still reached an inbox because the spoofed executive identity had been added as an allowed sender.
ReliaQuest Researchers indicates that,attackers are exploiting the gap as an operationally simple internal-impersonation method rather than as a niche proof of concept.
Self-addressed messages and familiar business workflows can make a spoofed internal email especially persuasive, increasing the likelihood of credential harvesting, payment fraud, malware delivery, or business email compromise.
Organizations should keep RejectDirectSend enabled, but must not regard it as a complete defense against anonymous internal spoofing.
Microsoft’s own Direct Send guidance states that the setting applies when the P1 envelope-sender domain is an accepted domain; it does not cover an empty sender value.
The strongest compensating control is an inbound partner connector restricted to approved source IP addresses or authenticated using a trusted TLS certificate.
ReliaQuest reported that IP-restricted inbound connectors blocked every Direct Send attempt during testing regardless of whether the envelope sender was populated or empty, because enforcement occurred against the sending source rather than the bypassed sender-domain condition.
Microsoft ecosystem guidance similarly recommends restricting inbound traffic to known partner IP ranges or certificates.
Security teams should also review every exception capable of overriding phishing verdicts, including allowed-sender policies, safe-sender lists, Tenant Allow/Block List entries, and transport rules that alter spam confidence.
Detection engineering should prioritize mail-flow events where Return-Path: <> appears alongside a visible From: address using an accepted internal domain, particularly when SPF, DKIM, or DMARC fails and the message is delivered under an allow rule.
The finding underscores a recurring email-security lesson: transport acceptance, authentication validation, antispam classification, and inbox placement are separate control points.
Restricting Direct Send to explicitly approved infrastructure and eliminating trust exceptions for highly impersonated users provides a more durable defense than relying on a single sender-domain validation control.
★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
