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.
[gap height=”40px”]
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:
[featured_box img=”56748″ pos=”left”]
If your MX record points to a third-party spam filtering service like Mimecast or Proofpoint, you’re already halfway there. Mimecast handles spam checks, then passes the emails along. Exchange Online is more inclined to allow those messages through, but you’ll want to make sure you’ve got a connector configured in Microsoft 365 that authorizes your third-party service’s IP ranges. So long as emails arrive via an authorized connector, RejectDirectSend will allow them through.
[/featured_box]
[gap height=”25px”]
[featured_box img=”56747″ pos=”left”]
If your MX points directly at your mail.protection.outlook.com address, you’ll need to configure a connector specifically for each third-party app. This tells Exchange Online that these emails are authorized to come in, so RejectDirectSend won’t block them.
[/featured_box]
[gap height=”50px”]
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.
[gap height=”50px”]
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.
[gap height=”50px”]
How should you prepare your environment to block direct send emails?
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
Take an inventory of systems authorized to send to your users
[/featured_box]
[gap height=”20px”]
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
Review or set up connectors in Microsoft 365, adding ones for third-party servers as needed
[/featured_box]
[gap height=”20px”]
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
Verify how devices relay mail to your users, ensuring secure and compliant configurations
[/featured_box]
[gap height=”20px”]
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
Enable RejectDirectSend with PowerShell:
Set-OrganizationConfig -RejectDirectSend $true
[/featured_box]
[gap height=”20px”]
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
Test everything thoroughly — third-party apps, printers, general inbound and outbound flow
[/featured_box]
[gap height=”20px”]
[featured_box img=”59730″ inline_svg=”0″ img_width=”20″ pos=”left”]
If problems arise, you can easily disable it:
Set-OrganizationConfig -RejectDirectSend $false
[/featured_box]
[gap height=”50px”]
[row]
[col span__sm=”12″ padding=”2em 2em 2em 2em” bg_color=”rgb(255, 220, 128)” bg_radius=”35″]
A Final Thought
RejectDirectSend may sound intimidating at first, but in reality it’s just a way to make sure only trusted senders are allowed to deliver mail into your tenant. With a bit of planning and some basic testing, it can be enabled smoothly and without disrupting users. Once it’s in place, it quietly closes a long-standing gap in inbound mail flow and then mostly gets out of the way. That’s the kind of security improvement most of us can appreciate.
[/col]
[/row]