After our recent post Introducing more control over Direct Send in Exchange Online, there have been more questions about scenarios that are not actually Direct Send such as senders being able to igno...
Updated Aug 07, 2025
Version 7.0
Blog Post
Big disrespect for "DirectSend" enabled by default for all. It's a shame. We received tons of phishing emails from "our users" to our internal users. I checked Exchange On-premise, no issues, no submits of phishing emails there. Then I checked Exchange Online... Phishing sent from random non-MS IPs (from OVH cloud, for example), using DirectSend. With violation of SPF, DMARC, DKIM. With our users in "From" and "To" fields. Exchange Online submits all these scams and delivers them as legitimate emails. Without "This email is external" headers. Proofpoint Antispam on our MX addresses? Centralized routing via Exchange On-premise without allowing sending and receiving by ExO cloud? Microsoft don't care, ExO submits emails without authentication. Invalid SPF, violation of DMARC? Pff...
3 months of active exploitation by spammers and phishers (https://www.varonis.com/blog/direct-send-exploit ). Instead of emergency disabling "feature" for all you are writing an article "What is Direct Send and how to secure it". 4 trillion dollars company...
- Mithun_Rathinam
Microsoft
Renat Matveev , This hasn't been enabled recently. Direct Send really is how any SMTP server works, it listens on port 25 and accepts messages addressed to recipients within the tenant's accepted domains. However, by design, the basic SMTP protocol is inherently vulnerable to spam and spoofing, as it lacks built-in mechanisms to prevent such abuse. Implementing strong SPF, DKIM, and DMARC policies can significantly reduce the risk of unauthorized emails. That said, when your MX records point to a third-party service, it's always recommended to lock down your Exchange Online (EXO) tenant, as outlined in Step 4 of our documentation - https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud . With this configured, only mail that passes through an inbound connector is allowed into your tenant, otherwise it will be rejected.
4. Lock down your Exchange Online organization to only accept mail from your third-party service.
Create and configure a Partner inbound connector using either TlsSenderCertificateName (preferred) or SenderIpAddresses parameters, then set the corresponding RestrictDomainsToCertificate or RestrictDomainsToIPAddresses parameters to $True. Any messages that are smart-host routed directly to Exchange Online will be rejected (because they didn't arrive over a connection using specified certificate or from the specified IP addresses).
Microsoft understands the recent concerns around Direct Send, and while the attention is valid, it's important to clarify that SPF validation does occur for Direct Send messages. These emails are also subject to Compauth evaluation, and the final verdict can vary depending on how the domain’s MX records are configured.
So, while the reaction may seem heightened in some cases, it has helped surface scenarios where tenants may not be fully locked down, especially when inbound connectors aren't properly configured. This awareness has led to positive action, with many organizations now taking steps to strengthen their mail flow security. We believe the conversation is valuable and are committed to providing clear guidance to help secure Direct Send paths effectively.
I call BS on this one. We have SPF, DKIM and DMARC locked down and these messages still got through.
We setup a partner connector, since we use an email gateway, with IPs, however, even if you specify IPs the connector still allows ALL traffic through UNLESS you configure "RestrictDomainsToIPAddresses parameters to $True" via powershell. I mean to allow admins to add IPs to the connector via the GUI and not give them the "checkbox" to restrict the connector to those IPs is beyond me... very frustrating.
If we didn't have a partner connector, then how do we lock this down if Exchange allows all of these spoofed emails in, even with strict PF, DKIM, and DMARC controls? In reality the only way is to enable direct-send block. Such poor design. MSFT deserves to get all the flak for this poor design... disable this by default instead of exposing EVERY O365 tenant to drive-by-phishing attacks.
Why do folks add Abnormal Security on top of O365 or 3rd party email gateways in front of O365.... It's because O365 security is garbage...Hi. Thank you for this link.
An additional question: I have a single inbound connector from Ex On-Premise to ExO. ConnectorType: OnPremises, locked to IPs of Exchange On-premise servers. But DirectSend emails with phising were delivered from other IPs to ExO. Is it correct, that I need to create one more inbound connector with the same settings, but with ConnectorType = Partner, to prevent such deliveries from other IPs?
Thank you.
- Mithun_Rathinam
Renat Matveev , Yes, exactly, that's right. You can lock down your tenant using on-premises IPs by configuring an additional inbound partner connector. You can also safely add your Proofpoint IPs as well if you consider them a trusted source for certain connections to Exchange Online.
