Is M365 Direct Send just the normal internet SMTP port?

Posted by jsellens@reddit | sysadmin | View on Reddit | 21 comments

I feel like I must be missing something, because it "obviously" can't be this.

In relation to recent spam/phishing campaigns, I've seen a number of people recommend that folks should disable M365 "Direct Send". Which according to the documentation is some magic feature where you can send mail directly from simple devices to M365, using SMTP over port 25 to company.mail.protection.outlook.com which seems to me to be just ordinary everyday internet SMTP.

So is Microsoft's documentation suggesting that Direct Send is some special thing just highlighting the assumption that M365's built-in spam protection is such garbage that "everyone" will pay for a third party MX service (Barracuda, etc) that uses MAPI or a connector or something to pass inbound mail to M365?

And are the recommendations that Direct Send should be disabled, just an indication that many people set up a separate MX service, but leave the default unauthenticated internet SMTP front door wide open, thereby completely negating the utility of their special expensive MX service?

It can't really be that dumb, can it? Surely I must be missing something here?

[-]

Beneficial-Gift5330@reddit

Switch it to 110 to adhere to email Standards

delicate_elise@reddit

Port 110 is POP, which deals with receiving email, not sending email.

You’re close to getting the point of the post. Think a bit harder and maybe you’ll figure out the impetus behind the post (or don’t bc you can’t).

Rentun@reddit

4.5.4.2. Receiving Strategy The SMTP server SHOULD attempt to keep a pending listen on the SMTP port (specified by IANA as port 25) at all times.

From rfc5321. Why are you being so snarky about something you're very obviously wrong about?

boglim_destroyer@reddit

Found the unemployed guy

fishter_uk@reddit

Or, you could stop being obtuse and actually say what you mean.

RainofOranges@reddit

The difference between Direct Send and regular anonymous email from the Internet is that Direct Send passes SPF/DKIM/DMARC and has an Envelope From of your domain. Those are the only things that separate the two. This is why it’s critical you have a properly set up DMARC policy. Admins saying to disable Direct Send are parroting a cargo cult “fix”.

The way people talk about it, you’d think Microsoft left open a secret door for phishing and all an attacker has to do is spoof who they’re phishing. Of course that’s not true. I explain more in my comment here: https://www.reddit.com/r/sysadmin/s/6ZXATe3uRU

jwalker55@reddit

Exactly. A lot of "sysadmins" here seem clueless about how e-mail works.

slapjimmy@reddit

But why would MS set it up like this? It doesn't make any sense.

FlyingStarShip@reddit

It makes sense, it is misconfiguration that is causing all the issues, especially if someone has third party gateway and didn’t lock down m365.

Huh? But it's enabled by default?

Anyone can send to your publicly available MX record, it is up to you to configure and lock it down properly. We never had this issue because we lock it all down years ago

You are absolutely correct, I like this article from MS about it.

https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865

Master-IT-All@reddit

It changes the behavior when an SMTP connection lists the FROM address as an internal authoritative domain on the default connector.

With Direct Send enabled, when the FROM address is an internal authoritative domain instead of rejecting or requiring authentication the Exchange Online service will look at the SPF record for the domain and if the IP or host name are included it will allow the unauthenticated reception of email on the external transport.

When you disable Direct Send, any connection on external that includes an internal domain in the FROM field will be rejected or require authentication.

So for a tenant with SPF setup to only have the required record, required DKIM, and a restrictive DMARC of p=reject the Direct Send feature is enabled but not in use.

Nice to see someone else who actually knows what’s up with this. We had several tenants hit yesterday and DMARC p=quarantine completely fixed it since their SPF records were already set up right, and some needed DKIM enabled still (sigh). I didn’t disable Direct Send at all.

WDWKamala@reddit

It’s our experience that SPF records did not mitigate this issue at all.

sheps@reddit

Direct Send checks the SPF record and will reject the email if the check fails.

pourquoipasvous@reddit

Unfortunately it does not.

Not true

saltyslugga@reddit

Nope, you've got it right. Direct Send is literally just "anyone on the internet can hit your tenant's MX on port 25 and deliver mail claiming to be from your domain" and M365 will accept it as long as it passes basic checks.

The reason it gets abused is spammers send as you@yourdomain.com to you@yourdomain.com, and since it's hitting your own tenant's MX directly a lot of internal-sender allowlists and spam rules treat it softer than external mail. DMARC with p=reject catches most of it but plenty of tenants don't have that enforced.

And yeah, if you've got a third party gateway in front, leaving Direct Send open means attackers just skip the gateway entirely. Microsoft finally added a "Reject Direct Send" toggle in the EAC recently, worth flipping if you don't need it.

tensorfish@reddit

Pretty much yes. The risky bit is that Exchange Online will still accept anonymous mail at your tenant MX for your own accepted domains, so if you run a third-party gateway or have soft anti-spoof handling you've left a second front door open. 'Direct Send' is mostly Microsoft's tidy name for a path a lot of tenants forgot they were still allowing.