Moving Exchange Online Away from Unauthenticated Connections with Reject Send

If your tenant still has devices that send email to Exchange Online, you should pay attention to the April 28 announcement about more control over the Direct Send feature. This step is part of the overall campaign to improve the security of Exchange Online that’s included initiatives like removing support for Exchange Web Services (EWS) and only accepting inbound mail from supported versions of Exchange Server in hybrid configurations.

Direct Send is a method for devices or applications to unauthenticated send email to Exchange Online recipients using an external mail server using an accepted domain for a Microsoft 365 tenant. No mailbox is required, so Direct Send is a relatively painless way to set up an email connection to internal recipients (Exchange Online rejects messages sent to external recipients).

Authenticated Connections Preferred

Because authenticated connections are used, Microsoft would prefer customers to use client SMTP submission (SMTP AUTH) or SMTP relay instead of Direct Send. The announcement says that Reject Send is a new option to disable Direct Send by default. If they don’t need to use Direct Send, tenants should use Reject Send to block Direct Send because it’s a method that could be exploited by spammers.

SMTP AUTH is next on the list for upgrade as it will lose the ability to connect with Basic authentication in September 2025. Devices and apps that use basic auth today, for instance to send email using the PowerShell Send-MailMessage cmdlet, must be upgraded to use OAuth connections or they will lose the ability to send messages via Exchange Online. Authenticating SMTP connections via OAuth is not a matter of changing out cmdlets, so if a tenant hasn’t started that work to make sure that apps and devices continue working after the September deadline, they’re behind the curve and need to accelerate.

The Reject Send Feature

Direct Send email is anonymous (messages don’t come in via a connector). In the past, this didn’t matter so much because the messages came from devices or apps controlled by you and submitted using a domain owned by the organization. Reject Send works by updating the Exchange organization configuration to instruct the transport service to reject any unauthenticated messages submitted by Direct Send.

Reject Send is currently an opt-in feature, so the RejectDirectSend setting in the organization configuration is set to false. To enable Reject Send, connect to Exchange Online PowerShell as an administrator and run the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -RejectDirectSend $True

Exchange Online organizational settings need time to percolate to all the mailbox servers used by a tenant, so it could take up to 30 minutes before the update is effective across a tenant. Once the block is effective, messages submitted via Direct Send will then a 550 5.7.68 error. Of course, unless someone is checking devices for errors in mail transmission or notices that expected messages don’t arrive, those errors might remain undetected.

Microsoft says that they plan to enable Reject Send by default for new tenants. The logic here is impeccable. If you’ve never used the feature, don’t get the habit. Reject Send is a preview feature to allow customers to test. An issue with forwarding and Sender Rewriting Scheme (SRS) is documented in the announcement, and Microsoft does not provide a date for general availability.

Before Reject Send can reach general availability, Microsoft must deliver the promised “optics” (a report) to give administrators insight into the level of Direct Send traffic within a tenant. Assuming that the report turns up soon and unless big problems are uncovered during the preview, I’d expect Reject Send to be fully available by the end of 2025.

Connectors Required

It’s possible that some existing mail will be affected by enabling Reject Send. If so, that email must be authenticated by routing across a partner mail flow connector.

SMTP AUTH is the Immediate Priority

There’s not much else to say about Reject Send. If you have a test tenant that mimics the operational environment (complete with apps and devices), you should enable Reject Send and see what happens. You could do the same for the production tenant, but only when prepared to track problems with devices and apps. A better idea might be to wait for the promised report to understand the level of Direct Send traffic within the organization.

Given the looming deadline for SMTP AUTH to lose support for basic authentication, this is likely to remain the immediate priority for upgrade. September isn’t that far away, especially when the prime vacation period is in the middle.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.