Direct Send: Microsoft 365 Feature Abused by Threat Actors

A widespread phishing campaign is utilising Microsoft’s own infrastructure through Direct Send. The feature is designed to provide a simple method for on-premises devices and applications to send emails to recipients within the organisation.

Threat alert
July 30, 2025

A widespread phishing campaign is utilising Microsoft’s own infrastructure through Direct Send. The feature is designed to provide a simple method for on-premises devices and applications to send emails to recipients within the organisation.

Technically, Direct Send functions as an unauthenticated SMTP relay. It operates by allowing any system to connect to a tenant’s specific MX endpoint (the smart host) on TCP port 25. This architectural loophole allows the emails to be delivered to user inboxes despite correctly failing standard authentication checks.

The Attack Chain 

  • Reconnaissance: The attacker identifies a target organisation and constructs its Direct Send smart host address (company-com.mail.protection.outlook.com) based on its public email domain.
  • Target Enumeration: The attacker gathers a list of valid internal email addresses through OSINT or by guessing common naming conventions. A user’s own email address is spoofed as the sender, which can lower suspicion and bypass certain security rules
  • Execution: A single-line PowerShell command using the Send-MailMessage cmdlet is sufficient to craft and send the malicious email.  
    Send-MailMessage -SmtpServer company-com.mail.protection.outlook.com -To [email protected] -From [email protected] -Subject “New Voicemail” -Body “Please review”.
  • Payload Delivery: The email is crafted with a compelling social engineering lure and often contains a PDF attachment with an embedded QR code  

Analysis of the Headers

  • SPF: The sending IP address is not included in the target domain’s SPF DNS record. This results in a validation outcome of spf=softfail or fail.
  • DKIM: The message is not cryptographically signed with a key corresponding to the spoofed domain. This results in a validation outcome of dkim=none.
  • DMARC: the header even includes action=oreject, indicating that the sender’s DMARC policy explicitly requests that failing messages be rejected.
  • Received Header: The primary indicator is a Received: header showing a connection from an external IP address directly to the organisation’s *.mail.protection.outlook.com smart host.
  • X-MS-Exchange-CrossTenant-Id Header: This header should contain the organisation’s own Microsoft 365 tenant ID.
  • Anomalous User-Agents: Query email submission logs for the use of PowerShell tools as the user-agent. This is highly anomalous for legitimate end-user email activity and is a key TTP of this campaign.

Recommendations

  • Implementation of Microsoft’s “Reject Direct Send” feature, a tenant-level setting that explicitly blocks this unauthenticated mail flow vector.
  • Implementation via PowerShell: Administrators must use Exchange Online PowerShell to enable this feature.

           - Establish a connection: Connect-ExchangeOnline.

            - Enable the setting: Set-OrganizationConfig -RejectDirectSend $true.

  • Enable the setting: Set-OrganizationConfig -RejectDirectSend $true.
  • Verify the configuration: Get-OrganizationConfig | Select RejectDirectSend.
  • Enforcing strict DMARC policies and Configure Exchange Mail Flow Rules.