Microsoft 365 Direct Send Spoofing: What to Check Now

Microsoft 365 Direct Send spoofing can bypass the RejectDirectSend control when an unauthenticated sender leaves the SMTP envelope sender blank while putting an internal address in the visible From header. ReliaQuest reproduced that behavior in a controlled tenant in September 2026. The message was accepted and queued, but it failed authentication and went to Junk Email in that test. This is a tenant inbound-spoofing issue, not evidence that normal authenticated outbound mailboxes or cold-email sends have been bypassed.

What the Microsoft 365 Direct Send spoofing finding actually shows

The ReliaQuest Threat Research report describes a limitation in the scope of RejectDirectSend, not a Microsoft software vulnerability. Microsoft documents Direct Send as an unauthenticated method for devices and applications to send to recipients inside the same Microsoft 365 organization. It does not relay to external internet recipients.

ReliaQuest tested two otherwise similar messages against a tenant where RejectDirectSend was enabled. Both connected without credentials to the tenant's mail host and used the same internal IT support address in the visible From header.

The distinction matters because an email has more than one sender identity. The SMTP envelope sender drives routing and bounce handling. The From header is what a user normally sees in the message. RejectDirectSend evaluated the domain in the envelope sender in ReliaQuest's test. An empty value left no domain for that check, while the visible internal address remained in place.

A null reverse path is not automatically malicious. SMTP uses it legitimately for non-delivery reports, which is why a blanket rule that rejects every empty envelope sender can break valid mail flow. The useful detection is the combination: an empty envelope sender, an internal address in the visible From header, failed authentication, and an unexpected delivery outcome.

Our view: the practical failure is not that one field can be blank. It is that teams may treat one tenant setting as a complete internal-spoofing defense when message acceptance, filtering, connector restrictions, and user-visible trust are separate decisions.

Separate tenant protection from authenticated outbound sending

Sales leaders should not interpret this finding as proof that Microsoft 365 outbound mailboxes are unsafe or that an authenticated campaign platform can now send as any employee. The tested route was anonymous inbound mail sent directly to the tenant's Microsoft 365 MX endpoint. No mailbox login or OAuth token was used.

Microsoft's own comparison makes the boundaries clear:

• Client SMTP submission authenticates with a cloud mailbox and can send to internal or external recipients.
• SMTP relay authenticates the connection through an inbound connector, commonly using a static public IP.
• Direct Send requires no authentication, reaches only recipients in the organization's accepted domains, and is filtered as anonymous internet mail.
• High Volume Email uses an HVE account and is designed for internal-recipient volume.

An outbound team using OAuth-connected Microsoft 365 mailboxes is operating on a different path from the bypass ReliaQuest tested. Its normal risks still include compromised credentials, poor authentication alignment, excessive volume, weak list quality, and harmful tenant rules. Those concerns belong in your Microsoft 365 email deliverability review, but they should not be conflated with this Direct Send control gap.

That separation also changes ownership. IT or security should own inbound connectors, anti-phishing policy, mail flow rules, and message trace. Revenue operations should own the inventory of sales applications and devices that need to send. The two groups need one shared record of which systems use Direct Send and why.

Read the test outcome in the right order

ReliaQuest's null-envelope message was accepted, then classified as anonymous incoming mail. In the published test headers, ReliaQuest recorded spf=none, dkim=none, dmarc=fail, and compauth=none. Microsoft assigned the maximum spam confidence level, SCL 9, and routed the message to Junk Email.

That outcome proves three different controls acted at different stages:

1. RejectDirectSend did not reject the null-envelope transaction.
2. Authentication and anti-spam checks still identified the message as highly suspicious.
3. Mailbox placement was Junk Email in the controlled test, not the inbox.

ReliaQuest explicitly says the bypass does not guarantee inbox placement. Message content, source infrastructure, tenant configuration, and filtering exceptions can change the final verdict.

The same report describes one investigated case where a spoofed executive address was in an allowed-sender entry. Although the message failed authentication and was classified as high-confidence phishing, that exception allowed it to reach the inbox. This is why a safe-sender or transport-rule exception is not a harmless convenience. It can override a correct negative verdict.

Inventory every legitimate Direct Send dependency

Start with evidence rather than changing controls blindly. Ask the Exchange administrator for a list of devices, applications, connectors, and source IPs that are expected to send directly to the tenant. Common candidates include printers, scanners, monitoring tools, and line-of-business applications that cannot store modern credentials.

For every entry, record:

Use message trace and connector logs to compare the written inventory with actual traffic. A stale application entry can outlive the application itself. An unknown source using an internal From address is not documentation debt; it is an investigation item.

If a device can use an authenticated method, evaluate moving it. If Direct Send remains necessary, keep its scope narrow and measurable. Do not broaden a connector or allow rule merely to make one legacy device work.

Restrict Direct Send by source where the mail path allows it

ReliaQuest reports that an IP-restricted inbound connector blocked every Direct Send attempt in its testing, regardless of whether the envelope sender was populated. The connector evaluated source IP rather than the envelope domain, so the null-envelope condition did not bypass that control.

This does not mean every organization should copy a connector configuration without testing. Mail routing differs when an organization uses a secure email gateway, hybrid Exchange, third-party filtering, or multiple cloud services. Confirm the real source IP after every proxy and gateway hop, then validate both allowed and denied cases.

A controlled test should include:

• An approved device from an approved source IP
• The same visible From address from an unapproved IP
• A normal envelope sender and a null envelope sender
• A legitimate non-delivery report
• A message that fails SPF, DKIM, and DMARC
• Delivery with relevant allow rules enabled and disabled

Capture the SMTP response, message trace, authentication results, spam verdict, connector used, mailbox folder, and any alert. The goal is not only to block the reproduced message. It is to prove that legitimate device mail survives and that the blocked path leaves evidence an operator can find.

Audit every exception that can override filtering

ReliaQuest recommends reviewing allowed senders, allowed sender domains, Tenant Allow/Block List entries, mail flow rules that set spam confidence, and user-level safe senders. Add secure email gateway bypasses and connector-scoped exceptions if they exist in your environment.

Build one exception register with these fields:

• Exact address, domain, IP, or condition covered
• Business justification and named owner
• Control or verdict being overridden
• Date created, last reviewed, and expiry date
• Whether an executive, finance, procurement, or shared customer-facing identity is named
• Evidence that a narrower rule was tested

Remove entries nobody can justify. Replace domain-wide allowances with the smallest workable identity or source restriction. Pay special attention to executives and managers because an allow entry for a frequently impersonated address can convert a detected phish into inbox delivery.

Do not use SPF, DKIM, and DMARC as a substitute for this audit. Authentication gives filters evidence about sender identity, and our SPF, DKIM, and DMARC guide covers the outbound setup. An exception can still tell the tenant to accept or trust a message after those checks fail.

Hunt for the combined pattern, not an empty field alone

ReliaQuest investigated phishing examples from September 2025 through August 2026 that used empty envelope senders across multiple organizations. It confirmed RejectDirectSend was enabled in one tenant but could not determine that setting for the others. That evidence supports active use of the pattern, not a count of confirmed control bypasses.

The report says observed lures included document sharing, payments, remittance, procurement, loans, investments, voicemail, fax, and a meeting invitation. Recipients often held leadership or business-facing roles. Treat those details as investigation context, not a prevalence forecast.

A useful detection combines:

• Return-Path: <> or another indication of a null envelope sender
• A header From address in one of the tenant's accepted domains
• Anonymous or incoming message direction
• SPF, DKIM, DMARC, or composite authentication failure
• A phishing or high-spam verdict
• Delivery caused by an override, allow entry, or trusted path

Exclude legitimate bounce traffic through tested conditions instead of suppressing all null senders. Alert severity should rise when the displayed identity belongs to leadership, finance, procurement, IT support, or a shared customer-facing mailbox.

Also define the response. Search for related messages, remove confirmed phishing from mailboxes, block malicious infrastructure where appropriate, and investigate user interaction. Preserve the original headers and message trace so the tenant team can explain why the message was accepted and where each later control acted.

Give the outbound team a clear operating boundary

An outbound program should not need broad inbound trust exceptions. Its sending mailboxes should authenticate normally, use dedicated sending domains, and retain clear ownership of DNS, mailbox access, provider settings, and campaign logs. Our email infrastructure setup guide explains that separation.

Document these boundaries in the outbound runbook:

LeadHaste orchestrates 35+ tools, but more tools do not justify more trust. Each sender, connector, rule, and exception needs an owner. That is how infrastructure remains transferable and auditable instead of becoming a collection of invisible dependencies.

Make the decision from test evidence

The immediate response is not to shut down Microsoft 365 outbound sending. It is to determine whether your tenant permits Direct Send, which systems depend on it, whether approved source IP restrictions hold, and which exceptions can override a correct phishing verdict.

Close the review only when you have:

• A current Direct Send dependency inventory
• A tested allowed-source and denied-source path
• Evidence for normal and null envelope senders
• An exception register with owners and expiry dates
• A detection for null-envelope mail displaying an internal identity
• A response owner and a tested message-removal path
• A written boundary between tenant inbound controls and authenticated outbound sending

If you want to map those tenant boundaries alongside your sender inventory, domains, authentication, and campaign controls, we can do that during a free ICP and campaign-fit discovery call. Book your free ICP and campaign-fit discovery call →