If your organization runs Microsoft 365, there is a high probability that right now, today, an attacker could send an email to anyone in your company that appears to come from your CEO, your HR department, or your IT team—without ever compromising a single account or guessing a single password.

This is not a theoretical risk. It is an active, documented, and growing attack campaign that security firms including Varonis, Mimecast, Proofpoint, Barracuda, Cisco Talos, and IRONSCALES have all independently confirmed as one of the most significant email threats of 2025. [3][4][5] The attack vector is called Microsoft 365 Direct Send abuse, and the vast majority of organizations running Microsoft 365 remain exposed to it right now.

This article explains what Direct Send is, how attackers are exploiting it, what the real-world consequences look like, and exactly what your IT team needs to do to close the door.

What Is Microsoft 365 Direct Send?

Direct Send is a legitimate, built-in feature of Microsoft 365’s Exchange Online service. It was designed to solve a practical problem: office devices like multifunction printers, copiers, scanners, and older line-of-business applications often need to send emails internally—scan-to-email notifications, backup alerts, automated reports—but these legacy devices typically cannot support modern authentication protocols. [1][9]

Direct Send solves this by allowing devices and applications to send email directly to internal recipients by connecting to the organization’s Exchange Online smart host over port 25, without requiring any username, password, or authentication token. The smart host address follows a predictable format:

yourtenantname.mail.protection.outlook.com

This is also, notably, the same address as your organization’s MX record—publicly discoverable by anyone.

For its intended purpose, Direct Send is a reasonable convenience feature. The problem is that it is enabled by default for every Microsoft 365 tenant, and the lack of authentication requirement that makes it convenient for printers also makes it a perfect attack vector for threat actors.

How Attackers Are Exploiting It

The mechanics of a Direct Send attack are straightforward, which is part of what makes it so alarming.

An attacker needs only two pieces of information:

1. Your organization’s domain name (e.g., yourcompany.com)
2. At least one valid internal email address (easily obtained through LinkedIn, the company website, or previous data breaches)

With that information, the attacker connects directly to your Exchange Online smart host over port 25 and sends a spoofed email. The email can claim to come from any address at your domain—including the CEO, a member of the HR team, IT support, finance, or any other internal sender. [3]

Varonis researchers documented active campaigns in 2025 using Direct Send to deliver spoofed “internal” emails with QR codes, credential-harvesting phishing pages, and malware-laced attachments. [3][4][5]

The result: an email delivered directly to someone’s inbox that appears to have been sent by someone internal, from a completely external, unauthenticated source.

Why Standard Security Tools Don’t Catch It

This is where Direct Send abuse becomes particularly insidious. Organizations invest in email security tools—SPF, DKIM, DMARC, third-party email gateways, Microsoft Defender for Office 365—specifically to block spoofing and phishing. But Direct Send abuse undermines these controls in a fundamental way:

• SPF (Sender Policy Framework) validates that a sending IP is authorized to send on behalf of a domain. Because Direct Send routes through Microsoft’s own infrastructure, it can appear to pass SPF checks.
• DKIM (DomainKeys Identified Mail) cryptographically signs outbound email. Direct Send messages are not signed, but because they route through Microsoft servers, they can bypass the external-facing scrutiny applied to mail arriving from unknown third-party servers.
• DMARC relies on SPF and DKIM alignment. When both fail, DMARC should block the message—but the internal routing characteristics of Direct Send can cause these messages to be treated differently than external spoofing attempts, and in many tenant configurations, they still reach the inbox or junk folder.
• Third-party email security gateways typically focus on filtering inbound mail from external sources. Because Direct Send routes through Microsoft’s trusted infrastructure, it can bypass these perimeter controls entirely—arriving in the inbox before the gateway ever sees it. [4]
• “External Sender” warning banners are often not added to these messages, because from Exchange Online’s perspective, the email is routed as an internal message. Employees who have been trained to watch for external sender warnings receive no such signal.

The Real-World Consequences

Security researchers from multiple firms have documented the consequences when this vulnerability is successfully exploited. The attack chain typically unfolds in one of several ways:

Credential Harvesting via QR Code Phishing (“Quishing”)

The most prevalent campaign format documented in 2025 involves spoofed internal emails—appearing to come from HR, IT, or management—containing a PDF attachment. The PDF contains a QR code. The email instructs the recipient to scan the code to access a voicemail, review an updated employee handbook, confirm a bonus, or re-validate login credentials.

The QR code directs the victim to a convincing fake Microsoft 365 login page, where they enter their credentials—which are immediately captured by the attacker. [3][4][5]

Account Takeover and Lateral Phishing

Once credentials are stolen, the attacker has full access to the compromised mailbox. From there they can read confidential emails and documents, send further phishing messages from a now-legitimately-authenticated account, access connected services (SharePoint, Teams, OneDrive), and begin lateral movement through the organization.

Business Email Compromise (BEC)

Attackers use the internal trust established by a spoofed sender identity to execute financial fraud—typically by impersonating a CEO or CFO requesting urgent wire transfers, vendor payment redirections, or W-2 and payroll data for tax fraud. [10]

BEC attacks cost US businesses billions of dollars annually. According to FBI data covering October 2013 through December 2023, BEC scams resulted in exposed losses exceeding $55 billion globally. [10][13] Direct Send abuse makes these attacks more convincing and harder to detect because the “internal” email arrives without any of the usual warning indicators employees are trained to look for.

Malware Delivery

In some campaigns, the payload is not a phishing link but a malware-laced attachment—delivered as a seemingly routine internal document or notification. Because the email appears to come from inside the organization, recipients apply less scrutiny before opening attachments.

Why Most Organizations Are Still Exposed

In April 2025, Microsoft acknowledged the abuse publicly and introduced a tenant-level setting called RejectDirectSend that allows administrators to block all unauthenticated Direct Send traffic. This setting is currently disabled (off) by default, meaning every Microsoft 365 tenant set up before—and after—April 2025 remains vulnerable unless an administrator has explicitly enabled it. [7][8]

The reason most organizations haven’t yet closed this gap is simple: most IT administrators and business owners don’t know the setting exists, or haven’t prioritized it among the long list of Microsoft 365 security configurations to review.

How to Close the Door: A Step-by-Step Remediation Guide

Closing the Direct Send vulnerability requires a deliberate, sequenced approach. Rushing to flip the toggle without preparation can break legitimate internal workflows. Follow these steps carefully.

Step 1: Audit Your Tenant for Direct Send Usage

Before making any changes, you need to identify whether any legitimate systems in your organization are currently using Direct Send. Common sources include:

• Multifunction printers and copiers with scan-to-email configured
• Backup software sending success or failure notifications
• Monitoring and alerting platforms
• Line-of-business applications that email reports, tickets, or notifications
• Third-party services routing mail through your MX record

Option 1: Use the Historical Message Trace to generate a report with all inbound emails received without a connector. The report can be generated for the last 90 days:

powershell

Start-HistoricalSearch -ReportTitle DirectSendMessages -StartDate 012/01/2025 -EndDate 12/24/2025 -ReportType ConnectorReport -ConnectorType NoConnector -Direction Received -NotifyAddress admin@contoso.com

To generate the same report as above from the UI, you can use the Inbound messages report from Exchange Admin Center > Reports > Mail flow. Inbound messages and Outbound messages reports in the new EAC in Exchange Online | Microsoft Learn (Please note the exceptions where messages will not be included in these reports). [2]

Option 2: Organizations that have Defender for Office P2 subscription can use Threat Explorer and Advanced Hunting to generate additional reports. To audit for Direct Send activity (emails received in the tenant without a connector), use the Microsoft 365 Admin Center Mail Flow Report, or query Microsoft Defender Advanced Hunting using KQL:

This surfaces email arriving via Direct Send (unauthenticated, no connector) so you can identify the source IPs of legitimate senders before disabling the feature. [2][8]

Step 2: Migrate Legitimate Direct Send Users to Authenticated Alternatives

Every legitimate system you identified in Step 1 needs to be moved to an authenticated sending method before you disable Direct Send. The two primary options are:

Option A: SMTP AUTH (Microsoft 365 Authenticated SMTP Submission)
For devices and applications that support modern authentication, configure them to authenticate using a dedicated Microsoft 365 service account via SMTP AUTH on port 587. This is the recommended approach for most line-of-business applications and modern multifunction devices. [11]

Option B: Third-Party SMTP Relay Service (e.g., SMTP2GO, SendGrid)
For legacy devices that cannot support Microsoft’s authentication requirements, a third-party SMTP relay service provides an authenticated sending path that doesn’t rely on Direct Send. These services use a username and password for authentication and typically operate on port 587 or 2525 (avoiding the port 25 restrictions common in many network environments).

Option C: Microsoft 365 Connector with IP Restriction
For environments where neither of the above is feasible, you can create a dedicated inbound connector in Exchange Online that restricts Direct Send to specific, authorized IP addresses. This doesn’t eliminate the vulnerability entirely but significantly reduces the attack surface by preventing arbitrary external IPs from using the feature. [2]

Step 3: Enable RejectDirectSend via Exchange Online PowerShell

Once all legitimate Direct Send users have been migrated to authenticated alternatives, you are ready to close the door.

Prerequisites:

• You must be a Global Administrator or Exchange Administrator in your Microsoft 365 tenant
• The Exchange Online PowerShell module must be installed

Step 3a: Install the Exchange Online PowerShell Module (if not already installed)

Open PowerShell as Administrator and run:

Step 3b: Connect to Exchange Online

Sign in with your administrator credentials when prompted.

Step 3c: Check the Setting

If you tenant has not been updated, the output should confirm:

If you see True instead of False then your tenant is already secure.

If you are experiencing spam issues that you cannot explain we are here to help. Contact us so we can do a thorough investigation of your environment to identify the problem.

Step 3d: Enable RejectDirectSend

Step 3e: Verify the Setting

The output should confirm:

Allow approximately 30 minutes for the setting to propagate across all Microsoft cloud servers before testing. [8]

Step 3f: Test the Configuration

To confirm Direct Send is now blocked, attempt to send a test email using an unauthenticated connection:

If configured correctly, you will receive the following rejection:

This confirms the door is closed. [8]

Step 4: Harden the Rest of Your Email Authentication Stack

Disabling Direct Send is critical, but it is one layer of a complete email security posture. Verify and harden the following alongside it:

SPF (Sender Policy Framework)
Ensure your SPF record is current and authorizes all legitimate sending services. Review it periodically as you add new tools or services. [12]

DKIM (DomainKeys Identified Mail)
Ensure DKIM signing is enabled for your domain in Exchange Online, and for any third-party sending services you use. DKIM provides cryptographic verification that email hasn’t been tampered with in transit.

DMARC
If your DMARC policy is still at p=none (monitor only), plan a path to p=quarantine and ultimately p=reject. A DMARC policy at reject instructs receiving mail servers to discard messages that fail both SPF and DKIM alignment—providing the strongest protection against domain spoofing from external sources.

Conditional Access and Legacy Authentication
Restrict legacy authentication paths in Azure AD / Entra ID that are no longer in use. Legacy authentication protocols do not support MFA and represent a separate but related attack surface.

User Awareness Training
Even with all technical controls in place, employees remain a target. Train your team to recognize:

• Unexpected requests for credentials via email—regardless of apparent sender
• QR codes in email attachments as a new phishing delivery method (“quishing”)
• Urgent financial or HR-related requests that bypass normal approval channels
• The habit of verifying unusual requests through a second channel (phone, Teams message) before acting

One Important Caveat: Email Forwarding

When you enable RejectDirectSend, be aware of one edge case: if someone in your organization receives an email from an external party and that external party’s email system then forwards a reply back to an internal mailbox, the forwarded message may be rejected if the sending mail server does not support Sender Rewriting Scheme (SRS). Without SRS, the forwarded email retains the original sender’s address and lacks a valid connector in your tenant, causing it to be blocked. [8]

This is typically only relevant for specific mail forwarding scenarios. If you encounter unexpected rejection of legitimate forwarded mail after enabling RejectDirectSend, investigate whether a partner connector or SRS configuration is needed for those specific sending sources.

The Bottom Line

Microsoft 365 Direct Send was designed for convenience. In 2025, that convenience has become a documented, actively exploited attack vector that bypasses the email security controls most organizations depend on.

The fix exists. It is a single PowerShell command. The preparation required before running that command—auditing and migrating legitimate Direct Send users—is the heavier lift, but it is entirely manageable for any IT team or managed service provider.

If you manage your own Microsoft 365 environment, walk through the steps above. If you have an internal IT team, forward this article and ask them to confirm your tenant’s Direct Send status today.

If you are a CelereTech managed IT client, this remediation is being addressed as part of our proactive security review process. Reach out to your account team if you have questions or want to confirm the status of your tenant.

If you are not currently a CelereTech client and want to know whether your Microsoft 365 tenant is exposed—or want help executing this remediation correctly without breaking your existing workflows—contact us today to secure your organization.

Don’t wait for a breach to confirm that the door was left open.

References

[1] Microsoft Learn. “How to set up a multifunction device or application to send email using Microsoft 365 or Office 365.” https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

[2] Microsoft Community Hub. “Direct Send vs sending directly to an Exchange Online tenant.” https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865

[3] Varonis. “Ongoing Campaign Abuses Microsoft 365’s Direct Send to Deliver Phishing Emails.” https://www.varonis.com/blog/direct-send-exploit

[4] Mimecast. “Microsoft 365 Direct Send Abuse: Phishing Risks & Security Recommendations.” https://www.mimecast.com/threat-intelligence-hub/microsoft-direct-send-abuse/

[5] IRONSCALES. “Inside Job: Attackers Are Spoofing Emails with M365’s Direct Send.” https://ironscales.com/blog/inside-job-attackers-are-spoofing-emails-with-m365s-direct-send

[6] Proofpoint. “Exploiting Direct Send: Attackers Abuse Microsoft 365 to Deliver Internal Phishing Attacks.” https://www.proofpoint.com/us/blog/email-and-cloud-threats/attackers-abuse-m365-for-internal-phishing

[7] Microsoft Tech Community. “Introducing more control over Direct Send in Exchange Online.” https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790

[8] Microsoft Community Hub. “Direct Send vs sending directly to an Exchange Online tenant.” https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865

[9] Microsoft Learn. “Exchange Online – Pricing and Features.” https://learn.microsoft.com/en-us/exchange/exchange-online

[10] FBI. “Business Email Compromise.” https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/business-email-compromise

[11] Microsoft Learn. “Configure mail flow using connectors in Exchange Online.” https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/use-connectors-to-configure-mail-flow

[12] Microsoft Learn. “SPF record syntax for Microsoft 365.” https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure

[13] FBI. “Business Email Compromise: The $55 Billion Scam” https://www.ic3.gov/PSA/2024/PSA240911