Introduction

On June 27, 2025, Varonis published an article stating that Direct Send is used by attackers (https://www.varonis.com/blog/direct-send-exploit).

Personally, when I read their article I just thought “nothing new here, I was already showing this to my trainees back in 2016!”

I'm not questioning the quality of Varonis's article (which is well documented). What surprises me is that everyone seems shocked to discover that it's actually possible to send an anonymous email to their tenant.

A clarification is needed.

Direct Send feature

Direct Send in Exchange Online is nothing new: it has always existed in Exchange Online.

It relies on using your tenant’s smart host (your MX company-com.mail.protection.outlook.com), which accepts emails from any external source.
It is documented at https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

Direct Send requirements

  • Use of port 25 (TCP)
  • Sender address belonging to an accepted domain in Exchange Online
  • Public IP included in the domain’s SPF (not mandatory but highly recommended)

Direct Send limitations

  • Cannot send emails to external recipients outside the tenant
  • Risk of blocking if the IP is on a blacklist
  • Microsoft applies throttling to protect the service
  • Messages treated as anonymous emails (SPF, DKIM, DMARC checks still apply)

The problem with Direct Send (since forever)

If an attacker can send an email from a public IP authorized in your SPF, they can use Direct Send to spoof any address in your tenant.

If you included your corporate network’s public IP, it’s an open door to abuse.

Block uncontrolled SMTP(S) sending and limit the list of internal IPs (apps, MFPs).

Varonis-reported issue

In the Varonis article (link at the start of this article), point 4 is questioned (Messages treated as anonymous emails):

Because the email is routed through Microsoft’s infrastructure and appears to originate from within the tenant, it can bypass traditional email security controls

I don't know if Microsoft has changed anything, but on all my tenants, this type of email ends up in the junk folder. So I don't see any bypass of the controls.

Maybe my tenants are just well enough configured to avoid this issue (if you have any info, I'm all ears).

In any case, you can improve your tenant’s security by blocking Direct Send.

Block Direct Send

⚠️
The feature is currently in public preview, so be cautious before deploying it in production.

Blocking Direct Send requires Exchange administrator rights and the module. ExchangeOnlineManagement https://www.powershellgallery.com/packages/exchangeonlinemanagement

Connect-ExchangeOnline
Set-OrganizationConfig -RejectDirectSend $true

Once configured, if someone sends from one of your approved domains to your tenant, they will receive this error message:

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

Emails sent from external domains are still processed like regular emails and therefore will not be blocked.

Direct Send Reports

Before enabling this block, you’ll probably want to know if any emails are being sent via Direct Send. Unfortunately, as of today, Microsoft does not provide any report to identify messages received through this method.

Final note

Many would like to block all anonymous (unauthenticated) SMTP on the MX. That’s impossible: to receive email from the world, you must accept unauthenticated connections. Blocking that would mean blocking all inbound email.

Comments

banner-Bastien Perez
Bastien Perez's avatar

Freelance Microsoft 365 - Active Directory - Modern Workplace

France