Direct Send vs sending directly to an Exchange Online tenant

I tried replying to myself yesterday to avoid spamming the comments, but it was deleted twice; so if you see this deleted later, you'll know the mods have deleted it.

Direct Send, as defined in the blog post linked above in detail, is the term used for sending emails directly to your mailboxes from a domain you own without any user or on-premises connector authentication.

Just because you put "a domain you own" in the definition doesn't mean that what it allows. To be clear, there is NO requirement that you control the domain. You can just as easily send emails directly to an organization's mailboxes from domain that you DON'T own or control.

With the publicly known and accessible Exchange Online provided endpoint, anyone on the internet can send emails to your tenant by default. That is how email works. Customers who introduce complex routing to their mail flow may define that ability as a “loophole” and might not like it. If that is the case, it’s a situation created by a configuration decision (complexity was added into email routing) which then needs to be closed.

"That is how email works." That's absurd. Yes, it's true on the most basic technical level, but it's also true that MTAs know the difference between MAIL FROM and RCPT TO, and internal vs. external domains. By default, I would expect a MAIL FROM for an internal domain should not be allowed on port 25 unless the host that sent it is identified as an allowed sender. In fact, that's how I thought Exchange Online was configured by default, until this came to light. Furthermore, the idea that introducing "complex routing" is the cause of the issue is ridiculous; the behavior is consistent whether or not you configure additional connectors. A fresh M365 tenant with no connectors will accept unauthenticated mail in the same way as one with multiple connectors configured (which is the whole problem that those responding here don't seem to grasp).

I suspect that the decision to have the opposite behavior is to support legacy configurations, which I can certainly understand, to a point. But it's 2025; there's no good reason for this to be the default, and the pushback that admins are dum dums for being surprised at this revelation is pretty insulting.

Finally, the recommended tools to find Direct Send messages are not helpful. The historical message report shows you all message submissions, but doesn't tell you whether they were accepted or rejected. And Message Trace has a message ID filter but it doesn't work, so you have to target by time and manually find the message. And if you have a very simple setup with no connectors, you're not only going to find these anonymous, unauthenticated messages, but rather ALL messages that were received, because the "ConnectorType" will be null for every message. (There's a possibility I'm wrong here, but again, following the logic outlined in the post leads to this conclusion)

It's fair to note that Google has this same behavior on their "restricted server" endpoint (aspmx.l.google.com); however, in my testing, messages sent through this server are clearly marked as suspicious if they fail SPF, which is not the case with Microsoft. I've tested this on a both Google and Microsoft tenants whose domains have SPF softfail (~all). And at least it's a different endpoint, so it's at least clear that the intention is to send the email without authentication.