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
MicrosoftIf your MX record points to O365, then everyone is "direct sending" to you, correct. Blocking Direct Send is mainly for where you would not want your chosen ingress routes bypassed
"Blocking Direct Send is mainly for where you would not want your chosen ingress routes bypassed" - that's so lacking in technical detail it basically means nothing.
- Alisdair Douglas
Blocking direct send is for where you're MX points elsewhere... ie you don't want people bypassing the routes you specify in your MX record
- Arindam_Thokder
The RejectDirectSend setting which this article talks about is to control anonymous inbound email coming to your tenant using your own acepted domain. It can come through a separate ingress point, or directly to your tenant, both are covered. Many are facing issue where their ingress point is being bypassed, but they should use the partner connector control and not RejectDirectSend. Point is if someone already secured their tenant using IP/Certificate based Partner connector, they "MAY" not need RejectDirectSend setting at all (although it depends on the routing scenario)
You've made this both clearer and less clear to me at the same time.
What I'm reading in your reply is that customers with an external (non-MS) security gateway (foobar) may have an ingress MX record of contoso.foobar-services.net. That is then configured as a connector in the MS365 tenant. To avoid bypassing the foobar email security gateway, MS365 customers/administrators can use the RejectDirectSend setting to make the contoso-com.mail.protection.outlook.com inert to inbound email.
Assuming I have the above right, this part makes sense.
What doesn't make sense is that NONE of the above touches on emails specifically with a sender domain of contoso.com- if the above logic is desirable, SURELY that is desired for ALL mail and NOT JUST email sent claiming to be from contoso.com.
Again, Microsoft REALLY needs to clean up their communication to customers here. I agree with the other comments around the importance of the reporting.
If I'm now understanding what you're saying correctly - for an environment like mine, where we use the default FQDN given to us by EXO in our MX record, using the RejectDirectSend setting would be disastrous for mail flow.
