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
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