Detections
Analytics

6.5.5 (L2) Ensure Direct Send submissions are rejected

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Direct Send is a method used to send emails directly to an Exchange Online customer's hosted mailboxes from on-premises devices, applications, or third-party cloud services using the customer's own accepted domain. This method does not require any form of authentication because, by its nature, it mimics incoming anonymous emails from the internet, apart from the sender domain.

The recommended state is to configure RejectDirectSend to True.

Direct Send allows devices and applications to transmit unauthenticated email directly to Exchange Online. While this method may support legacy systems such as printers or scanners, it introduces significant security risks:

 - Unauthenticated Email Delivery: Direct Send does not require authentication, making it an attractive vector for threat actors to deliver spoofed or malicious emails that appear to originate from trusted internal sources.
 - Phishing and Spoofing Risks: Because these emails bypass standard authentication mechanisms, they can easily impersonate internal users or services, increasing the likelihood of successful phishing attacks.
 - Lack of Visibility and Control: Emails sent via Direct Send may not be subject to the same security policies, logging, or filtering as authenticated traffic, reducing the organization's ability to monitor and respond to threats effectively.

Threat research from Varonis has shown that attackers are actively exploiting Direct Send to impersonate internal accounts and distribute malicious content without needing to compromise any credentials. These campaigns have successfully targeted organizations by leveraging predictable infrastructure and public user data to craft convincing phishing emails. Because these messages originate from outside the tenant but appear internal, they often evade detection and filtering mechanisms.

Solution

To remediate using PowerShell:

 - Connect to Exchange Online using Connect-ExchangeOnline.
 - Run the following PowerShell command:

Set-OrganizationConfig -RejectDirectSend $true

Impact:

Microsoft has identified some known issues with disabling Direct Send:

 - There is a forwarding scenario that could be affected by this feature. It is possible that someone in your organization sends a message to a 3rd party and they in turn forward it to another mailbox in your organization. If the 3rd party's email provider does not support Sender Rewriting Scheme (SRS), the message will return with the original sender's address. Prior to this feature being enabled, those messages will already be punished by SPF failing but could still end up in inboxes. Enabling the Reject Direct Send feature without a partner mail flow connector being set up will lead to these messages being rejected outright.
 - If you are using the Azure Communication Services (ACS) to send emails to your tenant, and if those emails are sent using a "MAIL FROM" address that is one of your Microsoft 365 accepted domains, enabling RejectDirectSend would block those emails sent to your Microsoft 365 tenant. A solution for ACS traffic to be compatible with the setting is being worked on. In case the domains used to send emails from ACS are not one of the Microsoft 365 accepted domains or sub-domains, enabling RejectDirectSend should not have an impact on ACS traffic. If ACS email traffic is using an Exchange Online domain where the MX is pointed to a 3rd party service, please refer to the FAQ's below, which provide instructions on mail connectors required to enable traffic in Exchange Online.

See Also

https://workbench.cisecurity.org/benchmarks/22162

Item Details

Plugin: microsoft_azure

Control ID: 91874bfdb27a8ff3e50656baa49df004bb40fc0283247827d212dbe968feb920