M365 Direct Send: The Internal Phishing Vector Most Orgs Miss

Your CEO’s email lands in your CFO’s inbox. Subject line: “Urgent — need this wire out today.” The From: address is exact. SPF passes. DKIM passes. There’s no “External Sender” banner because Microsoft 365 treats the message as internal. Your CFO doesn’t hesitate.

Except the CEO didn’t send it. An attacker did, from the open internet, using nothing but your tenant name and a script.

This is Microsoft 365 Direct Send abuse — a phishing vector that lives inside a feature Microsoft ships enabled by default, that most organizations don’t know exists, and that bypasses the anti-phishing controls IT teams actually put money into. In our recent work with an accounting firm and a regulated client, we watched it in the wild. This post lays out how it works, why traditional defenses miss it, and the concrete configuration changes that stop it.

What Direct Send is, and why it exists

Direct Send is a Microsoft 365 mail flow option that lets on-premises devices — multifunction printers, scanners, line-of-business applications, ticketing systems — send email to recipients within your own tenant without authenticating. There’s no username, no password, no OAuth token. The device just points its SMTP client at a specific endpoint and Microsoft accepts the mail.

The endpoint follows a predictable format:

tenantname-com.mail.protection.outlook.com

Where tenantname-com is your primary verified domain with the dot replaced by a hyphen. If your primary domain is acme.com, the endpoint is acme-com.mail.protection.outlook.com. That’s it. Nothing hidden. Nothing secret. Anyone with an internet connection can resolve that hostname and open a TCP connection to port 25.

Microsoft designed this for legitimate operational reasons. The old-school office copier that scans-to-email doesn’t speak modern authentication. Neither does the legacy accounting system that emails invoices from a shared mailbox. Direct Send lets those workloads keep functioning without adding an on-prem SMTP relay. Sensible engineering trade-off. Sensible until you realize the same endpoint is reachable from Kazakhstan.

How the attack actually works

An attacker who wants to phish your CFO from your CEO’s identity needs three things:

1. Your Direct Send endpoint — trivially derivable from your domain name
2. The CEO’s email address — public on LinkedIn, in press releases, in the footer of any invoice
3. The CFO’s email address — also public

That’s the entire prerequisite list. No compromised account. No credential stuffing. No malware on a workstation. The attack is pure abuse of a design feature.

The attacker opens a raw SMTP session to the endpoint and issues something functionally equivalent to:

HELO attacker.local
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "Jane Smith, CEO" <[email protected]>
To: "Bob Jones, CFO" <[email protected]>
Subject: Urgent — wire needed today
Content-Type: text/plain

Bob — please push this wire before EOD. Details attached.
Jane
.
QUIT

Microsoft’s inbound infrastructure accepts the message, wraps it in Exchange Online Protection’s normal delivery pipeline, and drops it in the CFO’s inbox. Because the receiving Exchange server sees the message coming from Microsoft’s own IP space — the trusted MX for the tenant — most of the anti-abuse checks that normally flag spoofing don’t fire.

Why traditional defenses miss it

This is the part IT leadership finds hard to accept: the standard email security stack does not stop this attack out of the box.

SPF passes

Nearly every M365 tenant’s SPF record includes include:spf.protection.outlook.com — Microsoft’s shared SPF include. When a message hits your organization from Microsoft’s own outbound IPs, SPF authorizes the sender because Microsoft is, technically, an authorized sender for your domain. The record is doing exactly what it was designed to do. The attacker just happens to be using Microsoft’s own infrastructure to send.

DKIM often bypassed

Direct Send messages typically pick up a DKIM signature from Microsoft during transit. That signature is valid — the message really did pass through Microsoft’s infrastructure. DKIM was never designed to authenticate who wrote the message, only that the transport is authenticated. It doesn’t help you here.

DMARC often doesn’t help either

DMARC ties SPF or DKIM alignment to the visible From: header. In this attack, the From: header is [email protected], SPF passes for acme.com (because Microsoft is authorized), and DKIM alignment can be arranged to pass as well. Even a strict DMARC policy of p=reject won’t block it — because the alignment checks technically succeed.

“External Sender” banners don’t fire

The tenant treats the message as originating internally, so the visual cues most organizations trained users to look for — the yellow “This email is from outside your organization” banner, the mail flow rule that prepends [EXTERNAL] to subject lines — never trigger. The user sees a clean internal email with no red flags.

Anti-phishing policies weigh internal senders less

Microsoft Defender for Office 365’s anti-phishing engine and the Exchange Online Protection spam filter both apply less scrutiny to messages that appear internal. That’s a tuning decision — you don’t want to flag every internal calendar invite. But it means the exact vector an attacker cares most about (impersonating internal executives) gets the least filtering.

How to spot it in your tenant

Before you can fix a problem you have to see it. In our engagements the first sign is almost always a user report — “Did you actually send this? It looks weird.” — followed by a Message Trace that leaves the IT team confused because the headers look clean.

The tell is in the Received: chain and the SMTP conversation record. A legitimate internal message sent by a real user’s Outlook client traverses outbound Exchange Online before it comes back through inbound processing. A Direct Send abuse message skips that outbound leg — it never touched an authenticated session. Under Message Trace → Detailed report, look for:

• A Send external or connector-source event with no matching Submit event from an authenticated client
• The initiating IP address in the trace is external — not one of Microsoft’s outbound IP ranges and not one of your on-prem NAT egress IPs
• The header Authentication-Results shows SPF pass, DKIM pass, DMARC pass — and yet the connection origin is a hosting provider in a country your organization has no business in
• The message was accepted through tenantname-com.mail.protection.outlook.com without a corresponding user submission

If you’re not certain whether Direct Send is being used legitimately by any of your on-prem devices, run a Message Trace filter for the last 30 days scoped to your Direct Send endpoint and inventory the source IPs. Everything not from a device you own is suspect.

Five mitigations that actually work

You do not have to accept this attack as a fact of life. There are concrete controls, most of which cost nothing beyond the time to configure them.

1. Reject Direct Send at the tenant level (if you can)

Microsoft has been rolling out a tenant setting to reject unauthenticated internal email outright. In the Exchange admin center, look under Mail flow → Anti-spam settings, or via PowerShell:

Set-OrganizationConfig -RejectDirectSend $true

If nothing in your environment legitimately needs Direct Send, this single command closes the vector. This is the correct answer for most organizations. It is the correct answer for every federal contractor we’ve worked with.

2. Replace Direct Send with an authenticated SMTP connector

If you do have legitimate Direct Send workloads — a legacy scanner, a line-of-business app — the right architectural fix is to move them onto authenticated SMTP submission. Options in order of preference:

• OAuth 2.0 client credentials flow — the modern answer. Register an Azure AD app, grant it Mail.Send permission scoped to a specific mailbox, and update the device or app to authenticate with it.
• SMTP AUTH with a dedicated service account — legacy but functional. Requires SMTP AUTH be enabled at the tenant and mailbox level. Password rotates on schedule. Not our first choice but acceptable for constrained legacy devices.
• On-prem SMTP relay — for the shop that has an Exchange hybrid environment or a purpose-built SMTP gateway. The relay does the authentication upstream so the legacy device doesn’t have to.

Once you’ve moved every legitimate workload off Direct Send, disable Direct Send with the setting above and stop worrying about it.

3. Enforce Anti-Spoofing in Microsoft Defender for Office 365

Under Microsoft Defender → Policies → Anti-phishing, turn on spoof intelligence and set unauthenticated senders that impersonate protected users (executives, finance staff) to quarantine, not deliver. Add your executives and finance leads to the Users to protect list. This is not a substitute for closing Direct Send — a determined attacker will find bypasses — but it raises the cost of the attack significantly.

4. Add a transport rule for internal impersonation

Create an Exchange mail flow rule that inspects incoming mail and, if the message claims to be from an internal sender and the source connector is your Direct Send inbound path, either quarantines the message or applies a header tag your users have been trained to recognize. This is the safety net for tenants that can’t turn Direct Send off outright because of a legacy dependency.

5. Monitor and alert

Turn on Microsoft Defender’s threat explorer and configure alerts for unauthenticated internal mail. In a mature environment, ingest Message Trace and Threat Intelligence into your SIEM and build a detection for messages that pass SPF/DKIM/DMARC but originate from an IP not in your legitimate egress list. This catches novel bypasses that haven’t been remediated at the platform layer yet.

Why this matters more for federal and regulated environments

For a Sarbanes-Oxley-regulated public company, an executive impersonation that triggers a wire transfer is not just a fraud loss — it is a material internal-controls failure. For a CMMC Level 2 contractor, an internal phishing vector that bypasses your identity controls is a finding that surfaces on your next assessment. For a FedRAMP-authorized service provider, a documented tenant configuration that permits unauthenticated internal mail is a control gap under AC-4 and SI-8.

None of the five mitigations above cost licensing dollars. What they cost is an IT lead who knows the vector exists, has the administrative access to close it, and has the operational maturity to inventory the legitimate use cases first so nothing production breaks. That combination is what an experienced fractional IT director or federal-contracting-ready IT team brings.

Bottom line

Direct Send abuse is not novel and it is not exotic. It has been documented publicly since at least early 2024, Microsoft has been quietly rolling out a fix, and it still lives on in the vast majority of tenants because nobody thought to look for it. If your organization runs on Microsoft 365, run the Message Trace inventory this week. If you find no legitimate Direct Send use, run the RejectDirectSend command and move on with your day. If you find legitimate use, do the migration to authenticated SMTP. Either way, close the vector.

If you’d like a second set of eyes on your tenant configuration, or you’d rather have the diagnostic and remediation run by an outside team, reach out. We do this work — mostly for federal contractors, regulated financials, and Northern Virginia SMBs — and we’re happy to talk through what’s live in your environment.