Bypassing the Gate: Threat Actors Abuse O365 Direct Send

While reviewing detected in-the-wild phishing and malware campaigns, our research team at Inception Cyber AI observed a subset of incidents consistently tagged by our detection engine (NACE^TM) with the feature label “Rec via O365 Direct Send”. Under normal circumstances, this tag appears on messages originating from trusted internal sources—such as multi-function devices (printers, scanners, fax machines) or on-premises applications—relaying through Microsoft 365 without SMTP authentication.

However, deeper analysis revealed an anomaly: several of these tagged emails were originating directly from public IP addresses, not internal corporate infrastructure. This prompted a detailed hop-chain inspection, during which we identified that the messages were transiting Microsoft’s Direct Send SMTP endpoints without passing standard MX-based authentication checks. The investigation uncovered an ongoing series of phishing campaigns abusing this feature to deliver malicious content directly into corporate mailboxes, effectively bypassing traditional inbound security controls.

Image: in-the-wild Campaign emails seen with “O365 Direct Send” feature tags

Microsoft 365 Direct Send

Direct Send is an SMTP relay method within Exchange Online that enables sending email to internal and external recipients without SMTP AUTH. It is primarily intended for devices or services that cannot use authenticated submission—such as MFPs, on-premises scanners, or legacy applications. Messages are sent over TCP 25 to *.mail.protection.outlook.com, where the relay decision is based on the source IP trust relationship rather than user credentials. These emails are processed and delivered using Microsoft’s infrastructure, often resulting in SPF pass states and the perception of legitimacy despite lacking DKIM signatures or originating domain alignment.

How Threat Actors Are Abusing the Feature?

Adversaries have discovered that once they gain access to a compromised Microsoft 365 tenant, an exposed relay, or a misconfigured inbound connector, they can abuse Direct Send to distribute malicious emails that inherit Microsoft’s IP reputation. This allows them to:

• Send spoofed or fraudulent messages that bypass SPF and DMARC enforcement due to delivery through Microsoft’s trusted IP ranges.
• Hide in legitimate Microsoft delivery paths, blending with normal tenant-to-tenant traffic.
• Avoid authentication requirements entirely, removing MFA and credential logging from the delivery equation.
• Exploit the fact that many security gateways and filters apply reduced inspection depth for Microsoft-originating messages.

This combination of trust, reduced inspection, and minimal logging makes Direct Send a potent tool for delivering phishing kits, malicious payloads, or BEC lures without triggering conventional detection mechanisms.

Direct Send – Case Study

Image: Filtered Threat Detection Logs via NACE 2.0^TM

Observed Campaign Timeline: July-August 2025

Target: Seen targeting multiple financial corporations and cloud communications firms.

Objective: Credential harvesting via a phishing landing page.

Header Analysis:

The email in question carried the “Rec via O365 Direct Send” detection tag. Hop analysis revealed the following:

• The email originated from a non-Microsoft public IP (185[.]101[.]38[.]62), failing SPF and DMARC alignment for the spoofed domain norristownlawyers[.]com.
• Despite SPF failure, the message successfully entered the Microsoft mail flow via a frontend Direct Send endpoint (<hostname>.mail.protection.outlook.com).
• The Received chain confirmed that the malicious email traversed multiple internal Microsoft mail hops before final delivery to the target’s inbox.
• Authentication metadata indicated:

Abuse Mechanism:

The attacker directly connected to Microsoft’s SMTP infrastructure over TCP 25 using a compromised or open relay path, bypassing SPF enforcement at the ingress point. The lack of SMTP AUTH combined with Microsoft IP reputation allowed the email to slip past inbound policy controls.

INTENT-BASED THREAT PREVENTION^TM 

Image: Campaign Hits via NACE^TM

Our INTENT-BASED THREAT PREVENTION^TM AI Platform, neutralized this attack by correlating header artifacts with semantic analysis in real time. NACE^TM applied semantic and thematic analysis to every message, extracting higher-order feature tags such as Intent or the purpose of email, auxiliary features from attachment, call to action URL,  that remain stable even when the adversary rotates domains or payloads. NACE™ engine detected this Direct Send phishing campaign by correlating multiple anomalous signals across infrastructure, authentication, and semantic layers:

Contextual relationship between the authentication inconsistencies, hop-path deviations, and intent analysis, NACE™ assigned a high-confidence malicious verdict. The email was detected before the user could open the HTML attachment, preventing potential credential compromise.

Conclusion

The abuse of Microsoft 365’s Direct Send capability showcases a strategic shift in phishing and malware delivery methods. As demonstrated in this case, static indicators are insufficient—the SPF result was “fail,” yet the email still transited Microsoft infrastructure and landed in the target’s mailbox path. This reality highlights the critical importance of INTENT-BASED THREAT PREVENTION^TM AI Platform that analyses authentication anomalies, intent or the purpose of an email and the contextual relationship between them are used to derive the verdict. 

For defenders, mitigation should include tightening Direct Send permissions to trusted IP ranges, implementing mail flow rules to quarantine unauthenticated external Direct Send messages, and deploying advanced AI engines capable of recognizing adversarial intent even when the email originates from a trusted cloud provider.

Stay vigilant, stay secure.