On 3 September 2026 ReliaQuest's research team published a very simple experiment: leaving the SMTP envelope sender blank was enough for Exchange Online to accept an anonymous message, sent from outside with no credentials, that carried an employee's address in the From field. Microsoft's setting against that kind of impersonation, RejectDirectSend, was switched on in the test tenant and did not stop it. ReliaQuest backs the finding with real cases investigated between September 2025 and August 2026.
ReliaQuest does not class this as a vulnerability in Microsoft's software, and it notified Microsoft before publishing: it is a limit on what the control covers. RejectDirectSend compares the envelope-sender domain with the tenant's accepted domains, and an envelope with no sender has no domain to compare, so the message passes. That difference decides where the defence has to sit: in how inbound mail flow is configured, connectors and exceptions included, and not in a single switch.
At Hard2bit, a cybersecurity company that audits Microsoft 365 environments on a continuous basis, the pattern is a familiar one: many of the techniques that pay best for an attacker break no encryption and depend on no numbered CVE; they exploit legitimate features almost nobody watches, and Direct Send belongs to that family.
What is Direct Send, and why does it exist?
Exchange Online includes a sending path, Direct Send, so that multifunction printers, scanners and internal applications can mail the tenant's own mailboxes without authenticating. The reason is practical: a scanner that emails the document it has just digitised cannot hold credentials safely, so Microsoft lets it deliver through a smart host whose name follows a fixed pattern, along the lines of tenant.mail.protection.outlook.com.
Attackers trade on Direct Send's unauthenticated path. The host accepts mail from any source provided the recipient belongs to the tenant, and both its name and the internal address format (first.last@company.com) can be worked out from public sources. With the domain and one valid address, an outsider can send a message that appears to originate inside the organisation without touching any of its systems. Varonis documented a campaign of that kind across more than seventy organisations from May 2025.
The gap RejectDirectSend leaves
Microsoft answered with the RejectDirectSend setting, generally available since September 2025. When enabled, Exchange Online rejects anonymous Direct Send messages whose envelope-sender domain matches one of the tenant's accepted domains, provided they did not arrive through a trusted connector; the server returns a 550 5.7.68 error and the message is not delivered. The control works, but it weighs a single piece of data: the sender's domain.
ReliaQuest observed that the envelope-sender domain can be left out altogether. SMTP allows a null reverse path, written MAIL FROM:<>, which servers use every day for non-delivery reports. A message sent that way carries no domain in the envelope, RejectDirectSend finds no value to check and waves it through, while the From header, the one the user sees, can still show a convincing internal address, such as the IT support desk.
The test ran in a ReliaQuest tenant with RejectDirectSend enabled. Two messages, identical except for the envelope sender, were treated differently: the one carrying an accepted-domain address was rejected with the 550 5.7.68 error; the one with a null sender was accepted and queued for delivery. Neither required credentials, a compromised internal host, a registered lookalike domain or dedicated sending infrastructure.
Accepting a message is not delivering it to the inbox
Getting round RejectDirectSend does not guarantee the inbox. In ReliaQuest's test, Exchange Online marked the accepted message as anonymous and unauthenticated: SPF and DKIM failed, DMARC applied with action=oreject, and the filter assigned an SCL of 9, the highest spam confidence level, before leaving it in the Junk folder.
That the message landed in Junk matters because four separate decisions are involved: transport accepting the message, authentication validating it, antispam classifying it, and the system choosing the folder. A message with no envelope sender can clear the first and still land in Junk or quarantine, depending on policy. It can also land in the inbox, and what tips the balance is not the attack itself but the exceptions the organisation has configured.
ReliaQuest describes at least one case in which a message classed as high-confidence phishing, with every authentication check failed, reached the inbox. The impersonated executive's address was on the allowed-senders list, and the trust exception outweighed the filter's verdict. A safe-sender entry covering an executive or a finance mailbox is therefore a risk decision.
Who it targets, and with which lures
In the cases ReliaQuest investigated, recipients were concentrated in leadership, finance, procurement and customer-facing posts: people who process invoices, bids, payment instructions and documents shared with third parties. A payment or document lure is believable to someone who handles payments and documents as part of the job, and a compromise in those posts opens the way to fraud, data theft or wider access.
The bait was everyday, not sophisticated: shared-document notices, payment requests and remittance advices, tender invitations, investment offers and meeting notices. Several carried SVG attachments presented as voice recordings, a format the browser opens directly and that some security products handle unevenly. Mail addressed to oneself, with the recipient's own mailbox as the apparent sender, is one of the most consistent tells of the technique, and matches what Varonis and StrongestLayer told the trade press during 2025.
ReliaQuest sees the same null-sender pattern in unrelated organisations, which points to routine phishing activity rather than an isolated experiment or a coordinated campaign. It is a method of internal-identity spoofing that is cheap to run and needs no infrastructure of its own, and that is why it stays in use.
Why the usual controls miss it
The attack rests on assumed trust, not on elaborate technique. A message that looks internal skips many policy checks reserved for external senders, and tools that go by sender reputation, by the authentication result or by external-routing patterns treat it as trusted traffic. In the case StrongestLayer investigated, as Dark Reading reported, the message got past Microsoft Defender and third-party mail gateways.
Two further difficulties compound the misplaced trust: headers often arrive missing or malformed, which complicates tracing the origin, and the sending can be done from IP addresses in any country with command-line tools. The combination of an internal-looking sender, failed authentication and delivery under an exception is the blind spot a detection engineering team has to cover deliberately.
Detection: what to look for in mail-flow telemetry
The sharpest signal combines three elements in one message: an empty return path (Return-Path: <>), a From header with one of the organisation's accepted domains, and a source outside the tenant. Non-delivery reports generated by the tenant itself also carry a null sender, so it is the three together that separate this activity from legitimate traffic. With that rule, a SIEM receiving mail-flow telemetry can alert with few false positives.
Other behavioural signals strengthen the detection:
- Messages that failed SPF, DKIM or DMARC and were delivered anyway because an exception overrode the verdict; for instance, DMARC with action=oreject followed by delivery.
- Mail sent from a user to themselves, an unnatural pattern outside testing.
- Command-line user agents, such as PowerShell, in the sending path, and unusual source geolocations.
- SVG or PDF attachments presented as voicemails or faxes, a recurring theme in these campaigns.
None of those signals proves a follow-on compromise on its own, but every phishing message that reaches an inbox opens the door to credential theft, malware execution or payment fraud. For prioritisation they are social engineering attempts in a particularly effective disguise, and a form of business email compromise that needs no compromised account.
Defence: restrict the source, not just the sender
The most durable control assesses where the message comes from. An inbound connector restricted by IP address admits mail only from the inventoried devices and applications that need to send without authenticating. In ReliaQuest's testing it blocked every Direct Send attempt, with a filled or an empty envelope, because it decides on the source. That is where the defence belongs.
Around the IP-restricted connector, the remaining measures fall into place without treating RejectDirectSend as the end of the matter:
- RejectDirectSend should stay enabled, as one layer among several against internal impersonation.
- Review every exception able to override a filtering verdict: allowed senders and domains, Tenant Allow/Block List entries and mail-flow rules that adjust spam confidence. Note which ones cover an executive and withdraw those that cannot be justified.
- Apply a DMARC reject policy (p=reject) on top of a prior inventory of senders, as we set out in our DMARC snapshot of large Spanish companies.
- Stamp legitimate internal mail headers with an organisation identifier and quarantine messages that present themselves as internal without it, an option Microsoft itself offers.
- The SIEM has to receive the right mail sources to hunt this pattern; our guide on which logs to send to a SIEM explains how to prioritise them without the cost spiralling.
For organisations that route inbound mail through a gateway, the IP-restricted connector is a straightforward change. For the rest, the realistic defence while the connector is planned is to keep RejectDirectSend, cut trust exceptions to a minimum and watch for the null sender. These reviews are part of a Microsoft 365 security audit and of the daily work of a managed SOC.
What fails underneath
The null-sender trick reveals no cryptographic weakness and no hidden feature: it exploits the fact that the label 'internal' still works as a free pass. A message addressed to oneself, wrapped in a familiar business flow, persuades even though it has shown no proof of where it came from. RejectDirectSend validates a domain and the attacker replies by supplying none; as long as trust is granted on the look of the address and not on the proven origin of the message, a gap will remain.
The parallel with AiTM account takeover in Microsoft 365 and with device-code phishing is exact: there too a label of trust took the place of a check. At Hard2bit we see it often in reviews of corporate mail.
This article is informational and written from the defender's perspective. The null-sender technique is not a vulnerability in Microsoft's software but a limit in a control's scope, per ReliaQuest's own research. The settings, headers and constructs described (RejectDirectSend, MAIL FROM:<>, IP-restricted inbound connectors) come from public sources as of the date of publication and should be adapted to each organisation's inventory of senders and tooling; a restriction applied without a prior inventory can block legitimate mail. The figures and cases cited reflect what third parties published on the dates indicated.
