Mind the Gap: How to Lock Down Exchange Online Direct Send and Prevent Gateway Bypass

As a security architect, my focus is on improving an organization's security posture by identifying and closing vulnerabilities that exploit the seams of customers' infrastructure. A potentially dangerous—and surprisingly common—vulnerability arises not from a flaw in any single product, but from a simple misconfiguration between a third-party email security gateway and Microsoft Exchange Online.

These gaps allow attackers to completely bypass sophisticated email defenses and deliver malicious payloads directly to user inboxes. This is not just a theoretical risk; researchers at Varonis have recently uncovered threat actors actively exploiting this misconfiguration in phishing campaigns, targeting over 70 organizations since May 2025 [Direct Send Exploit]. These campaigns leverage the "Direct Send" feature to send spoofed emails that appear to originate from internal addresses, increasing the likelihood of users falling victim to credential theft and other malicious activities. This blog post will dissect this threat, clarify the terminology, and provide a concrete, step-by-step implementation plan to close this open door for good, without interrupting critical business services.

Per Microsoft: We appreciate Mandiant’s work to identify and responsibly report this issue. Our assessment determined that Direct Send is not a security vulnerability. We already provide customers with the ability to reject Direct Send messages and messages sent directly to them when they do not require this functionality. We are continuing to enhance security protections for our customers, including rejecting Direct Send messages by default for new customers starting in early 2026.

Demystifying "Direct Send"

To understand the misconfiguration, we first need to clarify what "Direct Send" is. While the security community uses the term to describe the bypass attack, "Direct Send" is also an officially documented method by Microsoft for a specific use case.

According to Microsoft's documentation, the legitimate purpose of Direct Send is to allow unauthenticated devices and applications, such as printers, scanners, or legacy Line of Business applications, to send emails. It works by sending email directly to your organization's Exchange Online SMTP endpoint (e.g., yourdomain-com.mail.protection.outlook.com). However, this method comes with specific conditions and limitations:

• Internal Recipients Only: It is designed only for sending messages to recipients inside your Microsoft 365 organization. It cannot be used to deliver mail to external email addresses.
• Static IP Recommended: The sending device or application should have a static public IP address which can be added to your organization’s Sender Policy Framework (SPF) record.
• Envelope Address Limitation: The envelope sender address (P1 Mail From) must belong to a domain that is listed as an accepted domain in your tenant.
• SPF Record: To prevent these emails from being marked as spam, this static IP address must be added to your domain's SPF record.
  • Note on NAT: It is crucial to use the public static IP address in your SPF record. Do not use private, internal IP addresses (e.g., 192.168.1.x), as these are not routable on the internet and will cause SPF checks to fail. For example, if your printer's outbound traffic is NAT'd to the public IP 203.0.113.55, your SPF record should include ip4:203.0.113.55.
• No Authentication: It does not require a licensed Microsoft 365 mailbox to send email.

It is important to understand that even when used legitimately, emails sent via Direct Send are treated by Microsoft 365 as anonymous and external. They are not automatically trusted. Consequently, all Exchange Online Protection (EOP) and Microsoft Defender for Office 365 scanning, filtering, and analysis will still apply to these messages.

The Real Vulnerability: The Gateway Bypass

The critical issue emerges when an organization places a third-party email security gateway (such as Mimecast, Proofpoint) in front of Microsoft 365. The correct mail flow should be: 

The vulnerability is the gateway bypass. Attackers know the predictable format of the Exchange Online SMTP endpoint and can easily target it, sending their malicious emails directly to it. This completely sidesteps the hardened, specialized third-party gateway that is supposed to be the first line of defense.

While the email is still scanned by Microsoft's native protections (EOP/Defender), the organization is now relying only on its Microsoft security configuration. If those settings are less stringent than the bypassed gateway's, or if there are misconfigurations or overly permissive rules (e.g., allow-listing by domain), a malicious email that the gateway would have blocked now has a much higher chance of being delivered to a user's inbox.

Anatomy of a Gateway Bypass Attack

A typical phishing campaign exploiting this misconfiguration follows these steps:

1. Reconnaissance: The attacker identifies the target organization's domain and its default Exchange Online Mail Exchange (MX) Record. They gather a list of valid email addresses, often from public sources.
2. Crafting the Phish: The attacker creates a convincing phishing email. A common tactic involves impersonating internal notifications for voicemail or faxes, often with a PDF attachment containing a QR code. When scanned, this "quishing" (QR code phishing) attack directs the user to a credential-harvesting website.
3. Execution & Bypass: Using a simple script, often in PowerShell, the attacker sends the spoofed email. They don't send it to the public MX record that points to the secure email gateway; instead, they send it directly to the Exchange Online endpoint, bypassing the primary security controls.
4. Delivery and Deception: The email lands in the user's inbox. Having bypassed the hardened gateway, it is now only subject to Microsoft's internal scanning. If it gets through, it may appear to originate from an internal source, making the user far more likely to trust it and fall victim to the attack.

How to Secure Your Mail Flow

Protecting your organization requires a methodical approach to avoid service interruption. The correct sequence is to first create secure pathways for your legitimate mail flow, verify they are working, and then disable the insecure, anonymous pathway.

Part 1: The Critical First Step - Create Secure Connectors

Before you block anything, you must first explicitly permit legitimate email traffic from your third-party gateway and any on-premises devices (printers, scanners or legacy LOB applications) that send mail.

To create a Partner Inbound Connector in the Exchange Admin Center (EAC) to lock down mail flow to trusted IP addresses, the steps outline in the section below can be followed:

Steps:

1. Gather Your IP Addresses:
   • Third-Party Gateway: Contact your email security vendor (e.g., Mimecast, Proofpoint) to get a definitive list of their public IP addresses that will be used to send email to your tenant.
   • On-Premises Devices: Compile a list of all public static IP addresses used by your internal applications and devices that need to send mail directly.
2. Update the SPF record to include the identified IPs.
3. Log in to the Exchange Admin Center.
4. Navigate to Mail flow and then select Connectors.
5. Click "Add a connector".
6. In the "New connector" window:
   • Connection from: Select "Partner Organization".
   • Click Next.
7. Name the connector: Give it a clear, descriptive name, such as "Inbound from [Your Email Security Vendor]" or "On-Premises Device Relay".
8. Authenticating sent email: Select "By verifying that the IP address of the sending server matches one of these IP addresses that belong to your partner organization". Click the "+" button and carefully add the IP addresses you gathered in Step 1.
9. Security restrictions:
   • Ensure the setting "Reject email messages if they aren't sent over TLS" is checked. 
   • Also it is recommended to check the setting "And require that the subject name of the certificate that the partner uses to authenticate to Office 365 matches this domain name"
10. Review and Create: Review the summary to ensure the settings and IP addresses are correct, and then click "Create connector".

Part 2: The Final Lockdown - Disable Unauthenticated Direct Send

After you have created and verified that all legitimate mail is flowing correctly through your new, secure connectors, you can proceed with the final lockdown step. This ensures any anonymous attempts to send email directly to your tenant are rejected.

Before you disable Direct Send: It is highly recommended to first identify any legitimate traffic that might still be using this path. You can generate a message trace report to find emails received without an inbound connector. This allows you to add any forgotten IPs to your connector before blocking them. There are 2 ways of doing this:

1. Using the Exchange Online Powershell to run a historical search:

Start-HistoricalSearch -ReportTitle DirectSendMessages -StartDate 09/01/2025 
-EndDate 10/01/2025 -ReportType ConnectorReport -ConnectorType NoConnector 
-Direction Received -NotifyAddress {your email address}

2. Using the UI by going to Exchange Admin Center > Reports > Mail flow and searching for the Inbound Messages Report. Select Request report and for Connector Type choose No Connector.

When you are ready, this final step ensures any anonymous attempts to send email directly to your tenant are rejected. The setting to block this is RejectDirectSend. By default, Direct Send is allowed (RejectDirectSend is set to $false), so you must explicitly enable this protection.

Use Exchange Online PowerShell to enable the RejectDirectSend feature.

Steps:

1. Connect to Exchange Online PowerShell. You will need administrative permissions to perform this action.
2. Run the following command to block all other unauthenticated Direct Send attempts:

Set-OrganizationConfig -RejectDirectSend $true

Note: This change can take up to 30 minutes to propagate across all Microsoft servers.

3. Verify the setting with this command:

Get-OrganizationConfig | Select RejectDirectSend

The output should show True.

Once enabled, any unauthorized Direct Send traffic originating from one of your organization's own domains will be rejected, and the sender will receive a non-delivery report (NDR) with the error code 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.

Conclusion

By following this two-part process, you have first built a secure bridge for your legitimate mail and then closed the insecure, open door behind it, preventing attackers from bypassing your defenses without causing any interruption to your services. 

The threat of gateway bypass is a potent reminder that security is often about the connections between systems. A simple configuration oversight can negate a significant investment in advanced email security. By understanding the true nature of this vulnerable misconfiguration and taking the decisive, ordered steps to implement an IP or certificate-restricted inbound connectors before disabling anonymous sends, you can close this dangerous oversight and ensure your defenses are working as intended.