In recent months, Varonis Threat Labs revealed a critical vulnerability in Exchange Online’s Direct Send feature, drawing widespread attention across the cybersecurity community.

Their findings highlighted how threat actors can exploit this loophole to spoof internal users and deliver malicious emails, without ever compromising a legitimate account. These attacks expose organizations to stealthy phishing and impersonation campaigns.

Use Case

This article breaks down the Direct Send feature in Exchange Online, helping organizations with third-party filtering understand its behavior and monitor its usage before considering tenant-wide deactivation.

Definition

What is Direct Send?

Direct Send is a feature in Exchange Online that allows any device to send emails directly to recipient mailboxes within your tenant, without needing to authenticate.

Leveraging this feature requires only knowledge of the tenant’s Exchange Online MX endpoint (e.g., contoso-com.mail.protection.outlook.com), which remains publicly accessible regardless of whether the organization’s MX records are configured to route mail through a third-party filtering service.

A practical example:

• Open PowerShell.
• Run the following command:

Send-MailMessage `
	-From "fakesender@contoso.com" `
	-To "recipient@contoso.com" `
	-Subject "Test Email using Direct Send" `
	-Body "This is a test email sent from PowerShell using Direct Send" `
	-SmtpServer "contoso-com.mail.protection.outlook.com"

• The email has been sent successfully.
• If we verify the user’s inbox, we’ll see that the email has been delivered.

What Direct Send is not

Submitting unauthenticated SMTP messages directly to the Exchange Online MX endpoint using sender or recipient domains that are not listed among the tenant’s accepted domains does not constitute a Direct Send configuration. In this scenario, Exchange Online does not enforce domain ownership checks tied to the tenant’s authoritative namespace. Instead, it processes the message as standard inbound mail, and will accept it as long as the recipient address is valid and routable within the service. This behavior reflects the default posture of Exchange Online’s MX infrastructure, which is designed to receive mail for any address hosted in the service, independent of sender domain affiliation. To demonstrate this behavior, we can re-execute the same PowerShell command as before, this time specifying a sender address associated with a domain that is not listed among our tenant’s accepted domains.

Send-MailMessage `
	-From "fakesender@litware.com" `
	-To "recipient@contoso.com" `
	-Subject "Test Email from external sender" `
	-Body "This is a test email sent from PowerShell from an external sender" `
	-SmtpServer "contoso-com.mail.protection.outlook.com"

When sending email using a domain that is not owned or authorized by your tenant, any authentication mechanisms configured for that domain—such as SPF, DKIM, or DMARC—should fail validation during message processing. This is because the sending infrastructure is not aligned with the domain’s published records. However, if your environment does not enforce these checks (e.g., via transport rules, anti-spam policies, or third-party filtering), the message may still be accepted and delivered despite failing authentication.

SMTP relay can also be easily confused with Direct Send. While both methods allow unauthenticated email submission, SMTP relay requires an explicitly configured inbound connector in Exchange Online. This connector must authorize the sending IP addresses or TLS certificates, ensuring that only trusted sources can relay mail into the tenant. In contrast, Direct Send does not rely on any connector and accepts mail directly to the tenant’s MX endpoint, making it more susceptible to abuse if not properly restricted.

Securing the tenant

In the following section, we’ll examine how to analyze mail flow to identify any messages sent via Direct Send when your MX records are pointed to a third-party service. We’ll then explore alternative configurations to enhance the security of outbound email delivery. Finally, once Direct Send usage has been ruled out, we’ll walk through the steps to safely disable it within your environment.

Prerequisites

Minimum roles and permissions:

• To perform a message trace in Exchange Online: Compliance Management
• To access Advanced Hunting in Defender XDR:
  • Email & collaboration metadata (read) under Security operations / Raw data in Defender XDR Unified RBAC or
  • Security Reader in Defender XDR Email & collaboration roles

Licenses:

• Microsoft Defender for Office Plan 2 (Optional)

Checking Direct Send usage

Option 1: Historical Message Trace.

# In Exchange Online PowerShell
Start-HistoricalSearch `
	-ReportTitle SearchTitle `
	-StartDate 01/01/2025 `
	-EndDate 01/31/2025 `
	-ReportType ConnectorReport `
	-ConnectorType NoConnector `
	-Direction Received `
	-NotifyAddress admin@contoso.com

Option 2: KQL query in Advanced Hunting for organizations with Defender for Office Plan 2.

EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain in ("your-accepted-domain-1", "your-accepted-domain-2", "your-accepted-domain-N")
| where EmailDirection == 'Inbound' and Connectors == '' and isnotempty(SenderIPv4)
| project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject, NetworkMessageId, InternetMessageId, EmailDirection, Connectors, SenderIPv4

If using the Message Trace method, the resulting emails must be filtered to include only those where both the sender and recipient domains belong to your tenant’s accepted domains.

This subset represents messages that were likely sent using Direct Send.

Disabling Direct Send for the tenant

To disable Direct Send for the entire tenant, run the following cmdlet:

# In Exchange Online PowerShell
Set-OrganizationConfig -RejectDirectSend $true

The changes may take up to 30 minutes to propagate. To confirm the change was successful, run the following cmdlet:

# In Exchange Online PowerShell
Get-OrganizationConfig | fl RejectDirectSend

The output must be True.

Once the new setting is applied, incoming messages sent using Direct Send will be rejected by the service with the following status message:

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

What if certain workloads still require unauthenticated submission?

If certain workloads still require unauthenticated submission, you can create inbound connectors in Exchange Online to allow mail from trusted sources. These connectors can authenticate incoming messages based on the sending IP address or a TLS certificate, ensuring that only approved systems can bypass the RejectDirectSend restriction. This approach maintains security while supporting legacy devices or applications that can’t use modern authentication. Step-by-step configuration of inbound connector:

1. Log in to Exchange Online Admin Center.
2. Go to Recipients –> Mail flow –> Connectors.
3. Add a connector.
4. In the New connector page, select Connection from Your organization’s email server.
5. Give the connector a name.
6. In Authenticating sent email, choose between:
   1. By verifying that the subject name on the certificate that the sending server uses to authenticate with Office 365 matches the domain entered in the text box below (recommended)
   2. By verifying that the IP address of the sending server matches one of the following IP addresses, which belong exclusively to your organization
7. Save the connector.

This way, even if Direct Send is disabled at the tenant level, unauthenticated emails will still be accepted if they originate from an IP address specified in the connector or are sent over a TLS connection with a certificate whose subject name matches the connector’s settings. This allows legacy devices or applications to continue sending mail without authentication, as long as they meet the connector’s criteria.

Conclusion

Direct Send in Exchange Online can be a hidden vulnerability, especially when MX records point to third-party services. If your organization doesn’t rely on it, disabling Direct Send improves security and helps prevent spoofing. For legacy systems that still need it, use authenticated connectors to stay protected.

In the next article in this series, we’ll focus on the Direct Send scenario where your MX records point to Exchange Online Protection.

References & Resources

• Ongoing Campaign Abuses Microsoft 365’s Direct Send to Deliver Phishing Emails | Varonis Blog
• Introducing more control over Direct Send in Exchange Online | Microsoft Community Hub
• Direct Send vs sending directly to an Exchange Online tenant | Microsoft Community Hub