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 Oct 06, 2025
Version 13.0
Blog Post
I'm replying a second time to your comment - I suspect the blog software is throttling or shadowing my replies.
I don't understand what Microsoft is talking about then. This documentation and blog post needs a major revamp. I suggest a venn-diagram or some visual tool like a flowchart to describe what DirectSend is and what it isn't.
I call back to my original reply (top parent in this thread/chain) - if DirectSend is just describing normal MTA behavior and there's no security risks when running it (as it is authenticating inbound mail using SPF) then .... well again, why are we inventing new terms to describe industry standard behavior?
Arindam_Thokder
Microsoft
MicrosoftLet me try to explain this one more time-
About this blog- This blog talks about "Direct send" (please open the link to understand Direct Send, it is different from bypassing your 3rd party MX and sending email directly to your tenant) where someone can send email directly to your tenant just like any SMTP Server, this is nothing different than how SMTP works. So, what is the need to write a blog about this? Direct send also allows someone to send email to users in your tenant using a from address as your own domain (an accepted domain of your own tenant). Usually if SPF, DKIM, DMARC of your domain is correctly configured, and in strict mode, these emails would either be sent to Junk email or quarantined or even blocked. But there are scenarios where it might not be possible for customers to keep it strict for many reasons. For those customers we have a new setting called "RejectDirectSend" to control this type of mail flow. And to explain this new setting, we wrote this blog. This setting works irrespective of MX pointing directly to your tenant or some 3rd party. Please read the blog again to understand how this setting works and how someone can accept emails from their own domain address (like printer/FAX machine etc.) even with this setting enabled.
Scenarios where customer's MX is pointing to a 3rd party and someone is directly sending to tenant bypassing the 3rd party MX - The RejectDirectSend setting is not going to help customers where someone is bypassing their MX and sending email to the tenant directly (and using any from address). To stop this, customer should follow Step 4 from Manage mail flow using a third-party cloud service with Exchange Online.
Still doesn't answer the question on why we need a whole separate term to describe natural MTA-to-MTA and SPF policy processing behavior.
I really think MS needs to reflect more on what they're doing here and why. Some (non-MS) persons say that SPF policy isn't working and that unauthenticated (not even by SPF) mail is being let through. MS seems to reject this claim. I personally have not yet tested it, so I can't say with any certainty.
All I know is how mail should work, and I know that Microsoft has invented a term where a term wasn't required.