Direct Send nightmare

[-]

techtornado@reddit (OP)

We are actively culling the tenants now, it is 100% possible in powershell

[-]

teriaavibes@reddit

You can, it is a simple PowerShell command.

Unless that changed since the last time I turned it off.

[-]

Coldwarjarhead@reddit

My understanding is that's no longer possible. It used to be, but not any more, apparently.

Been fighting with this for a week since it started getting really bad. Finally got it licked today with the connector to reject them.

[-]

teriaavibes@reddit

The documentation still presents it as valid, would need to double check it when I get home and have access to my tenants.

[-]

Educational_Boot315@reddit

Worked for me yesterday no problem. They have no idea what they are talking about.

[-]

Contrary to popular belief, not all tenants in 365 have the same capabilities and experiences. Aside from variations in licensing, region, and third-party integrations, even two customers with the exact same subscription may not see the same thing at the same time.

When Microsoft introduces changes in 365 they use a phased rollout approach. So one customer may have a feature while another one does not. One customer may see a new interface while another customer is forced to use the old one.

This has been true for years, so it shouldn't be surprising to anyone with experience with the platform.

[-]

Educational_Boot315@reddit

Is this a bot?

[-]

FarmboyJustice@reddit

Um no, this is not a bot, it's a comment.

[-]

Educational_Boot315@reddit

You are right a bot would have been less stupid.

[-]

FarmboyJustice@reddit

What exactly is your problem?

[-]

Devil_85_@reddit

Don’t think he knows really. Apparently has never heard of A/B testing before either.

[-]

itskdog@reddit

While they don't know the setting has been available for a long time and the gradual rollout is usually over months, not years.

[-]

FarmboyJustice@reddit

None of which has anything to do with why your brigade buddy called me a bot, then called me stupid. But hey, be a typical redditor and completely ignore the main point.

[-]

FarmboyJustice@reddit

The number of so-called sysadmins on here who don't realize this is a thing is actually pretty shocking.

[-]

Kanduh@reddit

Completely irrelevant considering the commenter said “it used to be possible, but not any more.” Microsoft wouldn’t enable it for your tenant then disable it, that’s not how public previews work.

Unless your tenant is GCC-High, DoD, or USNat/USSec you have this flag and cmdlet available via the EXO v3 Powershell module. GCC-High, DoD, and USNat/USSec tenants would need to use the inbound connector method that is publicly available for all tenants.

[-]

FarmboyJustice@reddit

Talk about irrelevant, nothing you said makes me wrong. I'm right. Microsoft rolls out changes to different tenants at different times. And no, that's NOT just public preview, thanks for playing, here's your consolation prize.

gif

[-]

FrivolousMe@reddit

They roll out at different times but they're not suddenly unrolling out changes that were already made last year

[-]

FarmboyJustice@reddit

Yep, Microsoft is 100% consistent across all tenants, all the time, without exception. Nobody ever experiences a problem that doesn't exist across the board for every tenant. That's why it's impossible for one person to be unable to find or use a feature when another person can do so successfully.

I'm such a fool for not realizing that Microsoft has perfected the art of instantaneous simultaneous perfection across the cloud.

Reality: EVERY DAY Microsoft reports that some features may not work for some tenants.

EVERY.
DAY.

If you don't know this, you're not a 365 admin. Period.

[-]

itskdog@reddit

The blog posts from Microsoft suggest this was added in 2024. It should have rolled out by now.

[-]

Break2FixIT@reddit

I just turned it off, scream test was verified good, and had to turn it on again.. the command works though.

[-]

teriaavibes@reddit

Thanks for the sanity check.

[-]

ranhalt@reddit

Dude…

[-]

howboutno55@reddit

I just did it today by running the exchange online powershell command to set allow direct send to false.

[-]

Due_Programmer_1258@reddit

Anecdotal I know, but I literally turned it off today via a one-liner.

[-]

iamnoone___@reddit

What happened when you tried.

[-]

Internet-of-cruft@reddit

It is still.

[-]

TheOneDeadXEra@reddit

I'm gonna have to ask my coworker what he's been doing all week then, because he's been disabling DS for clients to cut down on phishing that bypasses our ESG.

[-]

PhoenixVSPrime@reddit

This. Abusing direct send is becoming a very common attack vector. The spoofs kept coming until we disabled it and added the office public IP to the mx record and Created a connector for it.

Just do this on and make life simple

[-]

mspbay@reddit

All this is true BUT something happened last week where MS changed something where no protection is kicking in at all. We have worked with them to understand this issue and they have acknowledged it.

“Please note that all updates regarding this incident are now published directly by the engineering team actively working on the fix. These updates are visible in the Service Health Dashboard (SHD), under SHD ID EX1287056”

[-]

PauseIll3626@reddit

Have you been able to actually find this Service Health issue? They sent me the same SHD ID but it's not there.

[-]

ArboriaTS@reddit

If anyone in this thread needs to turn off the Direct send in bulk to multiple tenants, there is a "trending hotfixes" page in https://t3nantwiz.com/ that helps you do this in bulk to your tenants. There's a free trial that doesn't require credit card so its quick and painless.

[-]

TheOnlyKirb@reddit

We turned it off and didn't really run into any issues. Is there any real reason you still need it on? Not that I agree with the practice, but giving less logging and traceability is likely Microsofts way of saying "hey stop using this"

Only had one legacy system break and I was able to setup a connector to SendGrid as a replacement

[-]

retr0baD@reddit

That's my question. Is there a way to check if anything is using direct send?

[-]

OverdueBoring@reddit

Microsoft released a new reporting tool: https://techcommunity.microsoft.com/blog/exchange/change-optics-report-released-into-public-preview-to-showcase-messages-impacted-/4513047

[-]

analbumcover@reddit

Maybe helpful https://blog.admindroid.com/how-to-check-exchange-online-direct-send-email-activities/

[-]

Sunsparc@reddit

Point of order: It's Get-MessageTraceV2 now. Because creating a whole new cmdlet instead of updating the current one made sense I guess.

[-]

retr0baD@reddit

Thank you, I will try the mail flow report described in the article.

The EmailEvents table for Advanced Hunting unfortunately isn’t available with our licensing.

Be aware that if you’re using Azure Communication Service to send legitimate email, the headers will also include AuthAs: anonymous since it’s not an Exchange auth.

[-]

tsaico@reddit

Same, just some copiers... but we fixed that with smtp relay service and it doesnt come out the domain at all, but a sub

[-]

Coldwarjarhead@reddit

We just had to set up a connector to reject anything claiming to be coming from our domain that didn't originate from our public ip address.

[-]

CHRDT01@reddit

This is the way. Outside of one instance where we'd misconfigured an impersonation rule, it's been one of the most set-and-forget components of our email setup. Getting scanners, postfix-enabled linux hosts, etc. to send stuff is an absolute breeze.

[-]

TechFTP@reddit

Yup same here worked wonders

[-]

iceph03nix@reddit

We just disabled it. The biggest headache for use was internal users forwarding external calendar requests in outlook/teams, as it auto-spoofs the forwarders email for the original sender, which is such a hack

[-]

calculatetech@reddit

This is a real problem no one talks about.

[-]

hb_2410@reddit

It sucks mam 🥲

[-]

Able-Ambassador-921@reddit

Perhaps one of these will assist or just turn it off:

New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" -ConnectorType Partner -SenderDomains * -RestrictDomainsToCertificate $true -TlsSenderCertificateName *.contoso.com -RequireTls $true

or:

New-InboundConnector -Name "Reject mail not routed through MX" -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <#static list of on-premises IPs or IP ranges of the third-party service>

or:

Set-OrganizationConfig -RejectDirectSend $true

[-]

itskdog@reddit

I still don't entirely get why there are so many settings they don't expose through the EAC.

[-]

nousername1244@reddit

Direct Send + useless headers = basically "good luck tracing anything" 🙃

[-]

Slight-Blackberry813@reddit

Reading these threads makes me so much more confident in myself. Basic opsec has been recommending disabling this or at least restricting it to known IPs for a long time. Like over a decade now.

[-]

InevitableOk5017@reddit

Why is this still a post? It should have been disabled honestly by default by microcrap. But yes disable direct send and don’t forget about all the things your copiers are going to not deliver when it’s disabled.

[-]

youreensample@reddit

I've been creating a transport rule to block these and it seems to be effective so far.

Google: Microsoft 365 email transit rule to stop spoofing

for the AI generated summary and details.

[-]

Some_Team9618@reddit

We used KQL to verify the abuse and potential impact and just set to reject direct send via powershell.

From what we can tell nothing was impacted. Since we had an inbound connector for a dedicated IP our mail from our relay kept flowing.

At this point the scream test will let us know what was missed, but enabling the reject we weighed was the right call.

[-]

smokedzucchini@reddit

Here's a great guide we used (800 users) but I we are seeing a new variant evading the fix on some users this week.

https://thecloudtechnologist.com/2025/08/09/an-improved-approach-to-blocking-direct-send-abuse/

[-]

dwarftosser77@reddit

Finally migrated to O365 June last year. Got hit with the direct send impersonation the first week we moved. Disabled it that week. No more direct send problems.

[-]

CeC-P@reddit

We're a small MSP and we're one that doesn't do extensive audits of each customer before adding them. So, you could guess. And about 1/3 of our clients are not within reasonable driving distance for who the hell knows what reason.

[-]

tensorfish@reddit

Yep. The worst part is not even the spoofing, it's that Direct Send collapses the trail. Once it lands through your tenant MX, 127.0.0.1 tells you basically nothing useful, so if you can't disable it yet I would start stamping or separating that path now. Otherwise every spoof hunt turns into archaeology.