Why You Should Disable Direct Send in Exchange Online

Over the past few months, a phishing campaign has been actively targeting Microsoft 365 users by sending phishing emails, bypassing standard security checks. What makes this especially dangerous is that the attackers aren’t breaking into Microsoft 365 accounts. Instead, they’ve found a way to spoof internal users and deliver anonymous phishing emails using Direct Send functionality.

To address this risk, our blog will show you how to disable Direct Send in Exchange Online before it hits your organization.

Direct Send is a feature in Exchange Online that allows on-premises devices and applications to send emails from own domain to your organization’s mailboxes, without authentication. It works by routing messages through a smart host, typically in the format:

domainname.mail.protection.outlook.com

This setup was originally meant for internal systems, like printers or monitoring tools. Notably, the Exchange Online Direct Send feature doesn’t require the sender address to be linked to a valid mailbox. However, it should be a monitored address if you want to receive replies or non-delivery reports (NDRs). When an application or device sends email directly to Microsoft 365, it needs to connect over TCP port 25 for the message to be delivered.

Because of its simplicity and low barrier to entry, Direct Send has become an appealing option for attackers aimed at bypassing traditional email defenses. Below are the key factors that make Direct Send a security risk:

Lack of Authentication: Direct Send comes with a major drawback that there’s no authentication involved. That means attackers don’t need a username, password, or token to send mail that looks legitimate.

Easily Exploitable Target: The smart host (MX endpoint) follows a predictable naming pattern, and internal email addresses like hr@yourcompany.com. With just a domain name and a valid recipient, an attacker can send emails that appear to come from inside the organization.

In recent cases, attackers have used PowerShell to craft and send spoofed messages that seem to originate from trusted internal addresses. For example:

The emails were crafted to resemble voicemail notifications and often included a PDF attachment. Inside the PDF was a QR code that redirected users to a phishing site, where they trick users to enter their Microsoft 365 credentials.

Alongside the social engineering tactics, several technical patterns emerged during analysis of the campaign. These messages often follow a consistent pattern. They are sent from multiple IP addresses in the 139.28.X.X range and typically contain links to malicious domains like voice-e091b.firebaseapp[.]com and mv4lh.bsfff[.]es. Many of these messages originate from Ukrainian IP addresses. Since no authentication is required, there are no corresponding login events, making these emails harder to detect.

By default, Microsoft 365 allows emails to be sent using Direct Send, provided emails come from the organization’s accepted domain. Previously, you didn’t have a direct way to disable Direct Send in Microsoft 365, which posed a serious security concern. However, Microsoft has introduced a feature called Reject Direct Send that allows you to block unauthenticated direct send traffic at the tenant level. Here’s how you can disable Direct Send feature in Microsoft 365 using PowerShell:

• Connect to Exchange Online PowerShell using the below cmdlet.

• Run the following cmdlet to enable Reject Direct Send feature in your Microsoft 365.

• To verify the status of Reject Direct Send feature in your tenant, use the following cmdlet:

Note: It can take up to 30 minutes for the change to take effect across all Microsoft cloud servers. Once enabled, Reject Direct Send will block unauthenticated emails sent directly to your tenant.

If your organization uses Direct Send for legitimate purposes like scheduled scripts sending reports or alerts, enabling Reject Direct Send will cause those emails to be rejected. With the feature enabled, any received Direct Send messages will see the following message:

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

To continue sending these emails from specific applications or devices after enabling this setting, you’ll need to authenticate them. This can be done by configuring mail flow using connectors in Exchange Online. These connectors verify the email source, by IP address or certificate, and allow authenticated messages to bypass the Reject Direct Send feature.

⚠️ Important Note: If someone in your organization sends an email to a third party, and that third party forwards the message back to another internal mailbox, the message might be rejected if their email provider doesn’t support the Sender Rewriting Scheme (SRS). Without SRS, forwarded emails return with the original sender’s address. Previously, they might still reach inboxes despite SPF failure. But once Reject Direct Send is enabled, and there’s no partner connector in place, those messages will be blocked completely.

Apart from enabling the Reject Direct Send feature, you can follow the email security best practices in Microsoft 365 to safeguard your organization.

• Look for anomalies in message headers, such as external IPs sent to your smart host, and SPF/DKIM/DMARC failures.
• Wherever possible, migrate devices and applications to use authenticated SMTP client submission (SMTP AUTH) or SMTP relay with connectors that have specific IP restrictions.
• Use strict DMARC policies like (p=reject) to ensure that emails purporting to be from your domain.
• Configure SPF to ‘hardfail’ within Exchange Online Protection (EOP) to strongly indicate that emails not originating from authorized sources are illegitimate.
• Train users to recognize phishing attempts, using targeted attack simulation training to help users recognize and respond to threats effectively.
• Configure rules to flag or quarantine emails that appear to come from internal addresses but originate from external IPs.
• Enforce MFA in Microsoft 365 to ensure that stolen credentials alone aren’t enough for attackers to access compromised accounts.

We hope this post has provided valuable insights and steps to enable the Reject Direct Send feature in Microsoft 365. We’d love to hear your thoughts about this new feature, so feel free to share them in the comments below.