If you’ve recently come across the Exchange Online setting called RejectDirectSend, your first reaction may be, “Well, that sounds dangerous!” Any feature that promises to reject email can sound risky,  especially when you rely on third-party applications, scanners/printers, or automated systems to communicate with your users.

The reality is, RejectDirectSend is far less disruptive than it sounds. In practice, it’s a logical tightening of how Exchange Online accepts inbound mail. In many environments, it simply enforces patterns that are already considered best practice. With a bit of awareness and some light preparation, it’s very doable and far less risky than its name might suggest.

I’ve run into this more than once with clients. An end user reports a suspicious email, IT pulls the headers, and notices something off. The message didn’t come through the organization’s spam filter, never touched their email security gateway, yet still landed squarely in the user’s mailbox. At that point, the question shifts from this specific email to: why is anything allowed to bypass the intended mail flow at all?

That’s exactly the kind of gap RejectDirectSend is meant to address. Effectively, a malicious actor can bypass your spam filter and send an email directly to your tenant. What RejectDirectSend does is say, “Hey, I don’t know you and you haven’t been authenticated. Sorry pal, you’re not allowed.” It’s looking to validate authentication and prevent anonymous emails from delivering to your environment without prior authorization.

So, what does RejectDirectSend prevent? Here’s the short list:

• Direct domain spoofing (emails coming from your domain to your domain, but not originating within your domain)
• Unapproved SaaS tools emailing your end users
• Forgotten servers or devices sending email
• Attackers bypassing filtering by sending directly to Exchange Online Protection (EOP)

What it doesn’t do is prevent Bob from MyFavoriteFinanceCompany sending your users a legitimate email.

What about third-party apps and services you do want delivering email to your end users? Great question!

Let’s start with common SaaS applications, like Atlassian Cloud or Salesforce. There are two recommended ways to ensure their messages get through:

What about printers, on-prem servers, or developers trying to send mail to users in Microsoft 365?

If you have a hybrid Exchange setup, there’s likely already a connector configured between your on-prem Exchange servers and Microsoft 365 — probably set up when you ran your hybrid configuration wizard. Printers or devices relaying mail through Exchange are considered authorized and authenticated by Exchange Online, so RejectDirectSend won’t block them. You have other options available too, like sending directly to Exchange Online, but your printer needs to be modern enough to handle newer authentication methods.

Important to note: RejectDirectSend doesn’t replace SPF and DKIM

It doesn’t take SPF or DKIM into consideration — that’s a different layer of protection for outbound messages. You still want those set up properly, along with DMARC, to protect your domain and improve deliverability. RejectDirectSend is about inbound sender authentication at the transport layer.

How should you prepare your environment to block direct send emails?