Update 8/12/2025: Added the FAQ to the post. Also, to help shed more light on the Direct Send feature, we published a newer post called Direct Send vs sending directly to an Exchange Online tenant.
...
Updated Aug 29, 2025
Version 12.0
Blog Post
I got to say, I've read this article a couple times now and I'm still struggling to understand what on earth Microsoft is driving at with this feature/powershell/etc.
Microsoft refers to the P1 address. I don't know who invented this term, but I hate it. Just stick to RFC5321.MailFrom and RFC5322.From. I beg you. I am going to use those terms going forward.
It seems to me that what Microsoft is talking with "DirectSend" is for mail that meets ALL the following rules:
- Mail that is sent directly to a (Microsoft Exchange Online) MTA host for a given domain that is hosted by Microsoft. e.g. microsoft-com.mail.protection.outlook.com
AND - Mail that uses an RFC5321.MailFrom domain of the given domain that is hosted by Microsoft, e.g. microsoft.com. I'm assuming "strict" alignment is in play here (subdomains aren't subject to DirectSend logic).
AND - Where that RFC5321.MailFrom domain is authenticated/passes the SPF policy processing.
AND - Mail that is destined for an address within the given domain that is hosted by Microsoft (e.g. mailto:email address removed for privacy reasons).
AND - It doesn't matter whether the destination address exists or not, nor whether the destination address is a mailbox/distribution list/group/etc.
This begs the question .... how is such mail different from literally any other mail sent on the Internet? The only thing you could even argue is "unique" about it is that the mail's MailFrom (SPF authenticated) domain is the same as the destination address's domain.
This isn't a unique thing that happens for a lot of enterprises. External ESPs may generate mail and send that to ""internal"" addresses within the EXO "tenant". That could just be coincidence. Not necessarily bad or good - simply natural. That's how email works.
I think Microsoft really needs to clarify under what circumstances customers should disable DirectSend vs keep it on. If my understanding here is mostly correct, then disabling DirectSend should be (mostly) safe for us as all our email systems which would send mail into internal addresses have in EXO have different SPF domains or are using subdomains. But Microsoft is leaving a whole lot to the imagination with this blog post and none of this is clear.
Alisdair Douglas
Microsoft
MicrosoftDirect send is more about the following conditions
- Mail that is sent directly to a (Microsoft Exchange Online) MTA host for a given domain that is hosted by Microsoft. e.g. microsoft-com.mail.protection.outlook.com
AND - Mail that uses an RFC5321.MailFrom domain of the given domain that is hosted by Microsoft, e.g. microsoft.com.
that's "direct send" (or essentially, anonymous mail from the internet).
DBEB will reject if in place and recipient doesn't exist, but beyond that it is just essentially sending direct to the service via SMTP connection to the front door servers.
Is there no SPF authentication/policy processing then? If that's the case, then the blog post has incorrect language where it says:
"It is critical that an administrator updates their SPF record by adding the source IP address where the device, application, or third-party service will send from to prevent emails from being flagged as spam. If SPF is not properly configured, any email sent using Direct Send will likely be flagged as spam."
Further if this is the case, then Microsoft is not treating this like the security issue that it is.