Reducing abuse of Microsoft 365 Exchange Online’s Direct Send

Overview 

Microsoft 365 Exchange Online’s Direct Send is designed to solve an enterprise-scale operational challenge: certain devices and legacy applications such as multifunction printers, scanners, building systems, and older line‑of‑business apps, need to send email into the tenant but lack the ability to properly authenticate. Direct Send preserves business workflows by allowing messages from these appliances to bypass more rigorous authentication and security checks. 

Unfortunately, Direct Send’s ability for content to bypass standard security checks makes it an attractive target for exploitation. Cisco Talos has observed increased activity by malicious actors leveraging Direct Send as part of phishing campaigns and business email compromise (BEC) attacks. Public research from the broader community, including reporting by Varonis, Abnormal Security, Ironscales, Proofpoint, Barracuda, Mimecast, Arctic Wolf, and others, agree with Cisco Talos findings: Adversaries have actively targeted corporations using Direct Send in recent months. 

Microsoft Inc., for its part, has already introduced a Public Preview of the RejectDirectSend control and signaled future improvements, such as Direct Send-specific usage reports and an eventual “default‑off” posture for new tenants. These ongoing enhancements, layered with existing security controls, are helping organizations strengthen their defenses while still supporting the business-critical workflows that Direct Send was designed to enable.

How Direct Send is exploited 

Direct Send abuse is the opportunistic exploitation of a trusted pathway. Adversaries emulate device or application traffic and send unauthenticated messages that appear to originate from internal accounts and trusted systems. The research cited above describes recurring techniques, such as: 

• Impersonating internal users, executives, or IT help desks (e.g., observed by  Abnormal and Varonis) 
• Business-themed lures, such as task approvals, voicemail or service notifications, and wire or payment prompts (e.g., Proofpoint’s observations about social engineering payloads) 
• QR codes embedded in PDFs and low-content or empty-body messages carrying obfuscated attachments used to bypass traditional content filters and drive the user to credential harvesting pages (e.g., highlighted in Ironscales, Barracuda, and Mimecast reporting) 
• Use of trusted Exchange infrastructure and legitimate SMTP flows to inherit implicit trust and decrease payload scrutiny

“What happens when a feature built for convenience becomes an attacker’s perfect disguise?” – Abnormal Security, framing the dual‑use nature of Direct Send.

Legitimate dependencies still exist. Many enterprises have not fully migrated older scanning or workflow systems to authenticated submission (SMTP AUTH) or to partner connectors. A hasty blanket disablement without visibility and change planning can disrupt invoice processing, document distribution, or facilities notifications. That’s precisely why Microsoft is building reporting to help administrators sequence risk reduction without accidental business impact.

Examples

The examples in Figure 1 (victim information redacted) demonstrate very obvious attacks that were presumed to be internal messages and therefore bypassed sender verification that could have convicted these threats. 

Direct Send bypasses sender verification 

There are three key elements to email domain sender verification: 

1. DomainKeys-Identified Mail (DKIM) is a cryptographic signature of message headers and content. This can verify that the message was sent by a server with a key authorized by the owner of the sending domain. 
2. Sender Policy Framework (SPF) specifies a list of IP ranges that are authorized to send on behalf of the domain. 
3. Domain-based Message Authentication, Reporting and Conformance (DMARC) defines what to do with a domain’s noncompliant mail when it lacks a DKIM signature and SPF authorization. Senders can choose a DMARC policy that instructs recipients to reject this mail. This is increasingly common, especially with banks.

Had the previous examples in Figure 1 been scanned with DMARC, DKIM, and SPF, they would have been rejected. However, Direct Send prevents this sort of inspection.

Mitigation and recommendations 

With Direct Send abuse becoming more prevalent, it is critical for organizations to review their security posture related to Direct Send. Aligning with Microsoft’s guidance and community findings, Talos recommends: 

1. Disable or restrict Direct Send where feasible. 
   1. Inventory current reliance. Although forthcoming Microsoft reporting should make this more streamlined, creating or reviewing internal device inventories, SPF records, and connector configs. 
   2. Enable Set-OrganizationConfig -RejectDirectSend $true once you’ve validated mailflows for legitimate internal traffic.
2. Migrate devices to authenticated SMTP. 
   1. Prefer authenticated SMTP client submission (port 587) for devices and applications that can store modern credentials or leverage app-specific identities (Microsoft documentation). 
   2. Use SMTP relays with tightly scoped source IP restrictions only for devices that are unable to use authenticated submission.
3. Implement partner/inbound connectors for approved senders. 
   1. Establish certificate or IP-based partner connectors for third-party services legitimately sending with your accepted domains.
4. Strengthen authentication and alignment. 
   1. Maintain SPF with required authorized sending IPs; adopt Soft Fail (~all) per guidance from the Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) as well as Microsoft. 
   2. Enforce DKIM signing and monitor DMARC aggregate reports for anomalous internal-looking unauthenticated traffic.
5. Strengthen policy, access, and monitoring. 
   1. Restrict egress on port 25 from general user segments; only designated hosts should originate SMTP traffic. 
   2. Use Conditional Access or equivalent policies to block legacy authentication paths that are no longer justified. 
   3. Alert on unexpected internal domain messages lacking authentication.

“You can’t block what you don’t see.” – Ironscales, on visibility as a prerequisite to confident enforcement

These defenses layer on Microsoft’s platform controls, reducing attacker dwell time and shortening the detection-to-remediation window.

How Talos protects against Direct Send abuse 

Talos leverages advanced AI and machine learning to continuously analyze global email telemetry, campaign infrastructure, and evolving social engineering tactics — ensuring our customers stay ahead of emerging threats. Our security platform goes far beyond basic header checks, using behavioral analytics, deep content inspection, and continually adapting models to identify and neutralize sophisticated malicious actors before they target your organization. 

Contact Cisco Talos Incident Response to learn more about everything from proactively securing critical communications and endpoint protection, to security auditing and incident management. 

Acknowledgments: We appreciate the sustained efforts of Microsoft’s engineering and security teams and the broader research community whose transparent publications inform defenders worldwide. 

Cisco Talos Blog – ​Read More