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
I'm not really buying the "all SMTP servers behave this way" argument. Sure that's true out of the box, but try sending an unauthenticated message through the primary Gmail server and you'll get an error 5.7.0 Authentication Required.
Can you clarify what the specific recommendations are for tenants that DO point MX directly to the smart host? Obviously we can't enable RejectDirectSend in these cases, and some orgs may not be ready to enforce DMARC alignment. Sure would be helpful to just reject messages that aren't authenticated...
The article 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 makes a distinction between "Client SMTP Submission" and "DirectSend", but it seems in reality there is no difference between the two. I would like to allow the former and disallow the latter, but I can't understand how to do that.
- Arindam_Thokder
Microsoft
StringFolk - There is a huge difference between "Client SMTP Submission" and "DirectSend". Client SMTP Submission allows relay. Using this method, you can submit an email to your tenant to any external domain. DirectSend on the other hand does not allow relay, using direct send, you can only send email to recipients in your own domain. Anything else will cause an 5.7.0 Authentication Required error (just like Gmail example you mentioned).
Arindam_Thokder But as I understand it, for internal recipients, the only difference in the two is whether the client specifies authentication credentials; if not, the submission is considered DirectSend UNLESS there is a connector set up, right? So if I have a tenant whose domain's MX records point to their smart host, and I only want to allow messages that 1) Use an IP-authenticated connector (e.g. copiers), 2) Are internally generated (e.g. from Sharepoint) or 3) Are submitted by smtp clients using modern auth, how would I accomplish that?
Arindam_Thokder That does make sense. So basically DirectSend is built for those 3rd party devices you want only to have mail received to an internal recipient? And that's without authentication?
- Arindam_Thokder
That's right
StringFolk I agree. It seems odd to me to hear "this is the way SMTP operates" from some of the Microsoft guys. What's the point of adding in this feature if you're going to say "this is the way SMTP operates" with this feature. I mean what's the point? If there's a 'default send connector' built in that "operates SMTP" (I promise I'm not trying to be snarky or sarcastic with my quotes. Just trying to understand), then what would this feature even be used for? It seems like another default incoming/outgoing connector built in. It's almost like you're trying to re-invent the wheel here.
jberg7120 I think part of the issue is that these terms aren't well defined. Since there is only a single endpoint for all types of SMTP submission, there really is no systematic differentiation between the different types. Instead, a combination of factors is used to determine whether a submission is allowed. Some of these factors are visible/manageable by tenant admins via mail flow rules and connectors, but others are not (e.g. allow internal recipients only for unauthenticated submissions). That means that the definition of "Direct Send" doesn't really match what they've said here, which is essentially "Sending directly to the endpoint." -- not untrue, but also true of both IP-based connectors and authenticated smtp client submission.
- Mithun_Rathinam
Please follow the Arindam's response above for discussion. closing this one.
