The M365 Direct Send Vulnerability That Bypasses DMARC — and How MSPs Can Audit It

What Direct Send is and why it exists

Microsoft 365 supports three legitimate methods for getting email from devices and applications into Exchange Online: SMTP client submission, SMTP relay through a connector, and Direct Send. The first two require authentication. Direct Send does not.

Direct Send works by connecting directly to the tenant's Exchange Online MX endpoint on port 25 and submitting an email — no username, no password, no credentials of any kind. The message is accepted because it arrives at the tenant's own mail server and is destined for a recipient in that organisation's domain. Exchange Online processes it as internal mail and delivers it.

Microsoft introduced this capability to make it easy to configure legacy devices — multifunction printers, copiers, IoT sensors, older ERP systems — that don't support modern authentication protocols. The reasoning is understandable. The security implication is not immediately obvious: if anyone can submit mail to the MX endpoint without authentication, anyone with network access to that endpoint can send mail that appears to come from the organisation's own domain.

How Direct Send is configured in practice:

The standard setup — documented in Microsoft's own guidance — involves pointing a device's SMTP server setting to the tenant's [tenant].mail.protection.outlook.com MX endpoint on port 25, setting a From address within the tenant's accepted domain, and leaving authentication fields blank. Microsoft's documentation explicitly notes no credentials are required. It is in widespread use in organisations that haven't been given a reason to reconsider it.

Why it breaks SPF, DKIM, and DMARC simultaneously

A message sent via Direct Send carries no DKIM signature. The device submitting the message doesn't have access to the organisation's signing key, and it's not routing through Exchange Online's outbound infrastructure where signing would normally happen. The message goes straight from the device to the MX endpoint and is delivered internally — DKIM is simply absent.

SPF fails for the same structural reason. The source IP address of the message is the device or application's IP — a printer on the office LAN, a server in a data centre, or anything else. That IP is not listed in the organisation's SPF record, because SPF records enumerate authorised sending infrastructure, and an internal device submitting directly to the MX endpoint is not that.

DMARC then evaluates the combination: SPF fails (source IP not in SPF record, no alignment), DKIM fails (no signature present). The DMARC result is a hard failure. What happens next depends entirely on the receiving server's policy application — but because the message arrived via the organisation's own MX endpoint and Exchange Online delivered it internally, many configurations don't apply outbound DMARC logic to mail that never left the tenant in the first place. The message lands in the inbox regardless of the published policy.

The specific threat model:

phishing An attacker with access to the organisation's internal network — or who can reach the MX endpoint from outside — can send a message from ceo@company.com to any internal recipient. No credentials, no account compromise required.
manage_accounts The message displays no authentication warning signs in the recipient's mail client. It shows a legitimate From address from a domain the recipient recognises and trusts as internal.
visibility_off Because the mail never leaves the tenant, it does not generate DMARC aggregate report data. It is invisible to DMARC monitoring — you won't see it in your reporting infrastructure at all.

What makes this a serious MSP concern specifically

For MSPs, the risk is multiplied by the number of tenants under management. A single poorly configured tenant with Direct Send in use is one exposure point. A portfolio of fifty tenants where Direct Send was set up years ago for printers and has never been reviewed is fifty separate exposure points — each one a potential internal spoofing vector that bypasses all the email authentication infrastructure the MSP has put in place.

The risk isn't only from external attackers who somehow gain network access. Insider threats — a disgruntled employee, a contractor with temporary network access, or someone who discovers the configuration and recognises what it enables — can also abuse Direct Send without needing any elevated privileges or stolen credentials. They just need access to the network and knowledge of the MX hostname.

In practice, the MX hostname for any Exchange Online tenant is publicly discoverable via a simple DNS lookup. It is not a secret. The combination of a public MX endpoint and an unauthenticated submission path is, bluntly, an open relay for anyone who understands how it works.

A common scenario in the MSP community:

An MSP finishes a DMARC enforcement deployment for a client. SPF is tight, DKIM is configured, policy is at p=reject. The client has a multifunction printer that's been sending scan-to-email for three years via Direct Send — nobody touched it during the DMARC project because it "just worked." The printer continues to bypass DMARC silently. More concerning, any machine on that network can now do the same.

How to audit for Direct Send across client tenants

There is no native Microsoft 365 admin centre toggle that shows "Direct Send is in use." Identifying it requires reviewing mail flow logs to look for messages arriving at the MX endpoint without credentials. The starting point is the Exchange Online message trace.

In the Exchange admin centre, a message trace filtered to messages received from internal source IPs — devices on the LAN — that are delivered without an associated authenticated submission event will surface candidates for Direct Send traffic. The key indicators are a connector ID of null or empty, and source IPs that correspond to on-premises devices rather than Exchange Online's own sending infrastructure.

PowerShell provides a more direct path. The following retrieves recent inbound messages and surfaces those where the source IP belongs to the client's own on-premises infrastructure rather than Exchange Online:

# Retrieve messages from the last 48 hours flagged as received
# via unauthenticated submission (potential Direct Send traffic)
Get-MessageTrace -StartDate (Get-Date).AddDays(-2) `
  -EndDate (Get-Date) `
  -Status "Delivered" |
Where-Object { $_.SenderAddress -like "*@clientdomain.com" } |
Select-Object Received, SenderAddress, RecipientAddress,
              FromIP, MessageId |
Sort-Object Received -Descending

Review the FromIP field on messages sent from the client's own domain. IPs in the client's LAN range, or registered to on-premises infrastructure, that are consistently appearing as senders are the Direct Send candidates. Cross-reference those IPs with known printer and application inventory to confirm and document each legitimate source before any changes are made.

The remediation options — and when each applies

The correct remediation depends on whether the Direct Send traffic is legitimate (devices that genuinely need to send email) or can simply be disabled. The audit step above tells you which case you're in.

Option 1: Remove Direct Send entirely where it isn't needed

For tenants where the audit finds no legitimate Direct Send traffic — either it was never configured intentionally, or the devices that used it have been decommissioned — there is no remediation step required beyond confirming that no devices are currently using it. Document this as part of the tenant's security posture and add it to the periodic review checklist.

Option 2: Migrate devices to authenticated SMTP relay

For tenants where printers, scanners, or applications genuinely need to send email, the replacement for Direct Send is an authenticated SMTP relay connector. Microsoft 365 supports this through a connector scoped to the specific source IP ranges of the devices sending mail, requiring TLS, and routing through Exchange Online's authenticated submission infrastructure. Messages sent via this path receive DKIM signing and pass SPF.

For legacy devices that cannot support modern authentication protocols, the alternative is to route them through a dedicated SMTP relay service with static IPs that can be added to the SPF record — isolating the risk to a known, enumerated sending source rather than leaving the MX endpoint fully open.

Option 3: Transport rules to block unauthenticated internal impersonation

Where a full migration isn't immediately feasible, a targeted transport rule provides interim protection. The rule matches messages arriving at the MX endpoint with a From address in the organisation's own accepted domain, a source IP outside the authorised sending ranges, and no authentication credentials — and rejects or quarantines them. This doesn't eliminate Direct Send from the environment but does block the most obvious abuse vector while a proper migration is planned.

The SPF hardening step:

If clients still have ~all (softfail) in their SPF record, the Direct Send remediation is a good time to move to -all (hardfail). With authenticated relay in place and Direct Send closed, SPF hardfail can be applied without risk of breaking legitimate mail flow — and it removes the ambiguity that softfail leaves for receiving server filtering logic.

Why this won't show up in your DMARC reports

This is the part that catches MSPs off guard. DMARC aggregate reports are generated by receiving mail servers — external servers that process inbound mail from your clients' domains and report back on SPF and DKIM pass/fail results for messages they received during that period. DMARC reporting is, by design, about external delivery.

Messages submitted via Direct Send and delivered internally within the same Exchange Online tenant never route through an external receiving server. They don't generate aggregate report data. An MSP reviewing DMARC reports for a client where Direct Send abuse is occurring will see nothing unusual — there is no report entry for internal spoofing via Direct Send because no external reporting server ever processed those messages.

This means the audit described above — reviewing Exchange Online message traces and looking for unauthenticated submissions — is the only way to detect it. DMARC monitoring is essential and irreplaceable for external spoofing detection, but it has a structural blind spot for this specific attack vector. Alerting on unusual mail flow patterns within tenants, not just on external DMARC data, is what fills that gap.

What a complete monitoring posture covers:

public External spoofing: DMARC aggregate reports from external receiving servers — surfaces impersonation attempts targeting clients' domains from outside the tenant.
home Internal spoofing via Direct Send: Exchange Online message trace review for unauthenticated submissions — surfaces abuse of the MX endpoint from within the network.
dns DNS-level changes: Monitoring for SPF, DKIM, and DMARC record modifications — surfaces configuration drift introduced by third parties or unmanaged changes that create new gaps.

Adding Direct Send to the MSP client onboarding checklist

The most scalable response to this across a client portfolio is to make the Direct Send audit a standard step in both onboarding and periodic security reviews. When taking on a new M365 client, the email security checklist should include identifying any devices or applications currently using Direct Send, documenting their legitimate use case, and beginning migration to authenticated relay as part of the initial hardening work.

For existing clients where DMARC enforcement has already been deployed, a point-in-time Direct Send audit — run against the last 30 days of message trace data — will surface any ongoing exposure. In most cases, the findings fall into two categories: known legacy devices that can be migrated to authenticated relay with minimal effort, and no Direct Send traffic at all. The rare third category — active, unexpected internal traffic from unknown source IPs — warrants immediate investigation.

Closing Direct Send is one of the few hardening steps with no trade-off against security: legitimate mail doesn't need it (authenticated relay serves every device that Direct Send supports), and removing it eliminates a spoofing vector that bypasses every layer of email authentication an MSP has put in place. Across a portfolio of clients, the cumulative risk reduction is significant.