In a lot of the Microsoft 365 environments I work in, the same weak spot keeps turning up. Messages claim to come from your own domain and arrive unauthenticated at your MX endpoint. That is classic Direct Send abuse. Attackers like it for phishing that looks internal, because these messages often get past SPF, DKIM and DMARC even when those are configured well. Until now there was no simple way to reject Direct Send at the service level. Microsoft's new Reject Direct Send setting changes that and gives admins a direct, effective way to shut this down.

Direct Send gives attackers an easy route for internal-looking phishing

With Direct Send, a device or app delivers email straight to your MX endpoint, uses your domain as the sender and never authenticates. You see this a lot with printers, scanners and custom apps that can't do SMTP AUTH or modern mail submission. The problem is that phishers can do exactly the same thing. Their messages look internal, slip past anti-spoofing and end up in users' mailboxes. Even tenants with strict SPF, DKIM and DMARC records have had trouble spotting and blocking this mail in practice. The advice has always been to move devices and apps off Direct Send, yet most organizations still have legacy systems that use it, and nobody notices them until something goes wrong.

Exchange Online can now reject Direct Send at the transport level

Microsoft announced the new Reject Direct Send option for Exchange Online in late April 2025. It lets you reject, on the server side, any unauthenticated SMTP traffic to your accepted domains when your own domain also appears as the sender. This is not an add-on to SPF or DMARC. It's a transport-level control that cuts off the attack path completely. I've spent years tracking down spoofed internal mail, so for admins like me this upgrade is overdue. You no longer have to rely only on DNS records or message hygiene settings, because Reject Direct Send closes the gap where it starts.

Message trace shows who still relies on Direct Send

Before you turn it on, you have to know which devices and apps in your environment still depend on Direct Send. In most tenants that list goes beyond the obvious printers. Old business apps and homegrown systems are often sending mail on port 25 without anyone thinking about them. Exchange Online's message trace is the tool for this. Go to Exchange admin center → Mail flow → Message trace and filter for messages where the sender matches your domain and the authentication method is empty. You'll quickly see which IPs and sources send with unauthenticated internal sender addresses.

Pro tip: Use the modern message trace in Exchange admin center and filter for your domain as sender plus no authentication. That reliably turns up the actual Direct Send sources. Microsoft's documentation on modern message trace walks through it step by step.

Every time I do this, I find more than old printers. Legacy apps and integration scripts show up too, some of them configured years ago and forgotten until a project like this one.

Every device and app needs a secure alternative before the switch

If you want to reject Direct Send, each device and app has to move to a secure alternative first. In practice that is usually one of these:

  • SMTP AUTH client submission: Devices/apps authenticate against smtp.office365.com with a dedicated mailbox. SMTP AUTH has to be enabled for that account. Details are in Microsoft's setup guide for multifunction devices and apps.
  • Partner Inbound Connector: Devices send through a connector that authenticates by certificate or trusted IP (configured in Exchange Online admin center → Mail flow → Connectors).
  • Azure Communication Services: For cloud-facing scenarios, or when the SMTP options don't cover your needs.

What matters is the end state. Once you've migrated, no unauthenticated mail with an internal sender should reach your MX endpoint at all. SPF, DKIM and DMARC help, but only this new feature actually closes the loophole. If you want more on DNS-based anti-spoofing, I've covered it in SPF, DKIM & DMARC for Exchange Online: DNS done right.

One PowerShell command turns on Reject Direct Send

When your senders are inventoried and the last printer and app has been migrated, you can enable Reject Direct Send. During the public preview this only works through Exchange Online PowerShell. You need "Organization Management" or a comparable admin role, plus at least an Exchange Online Plan 1 license.

# PowerShell 7, Exchange Online Management module v3+
Set-OrganizationConfig -RejectDirectSend $true

From then on, unauthenticated mail to your accepted domains with your own domain as the sender is rejected straight away. The Mermaid flowchart below shows the effect on mail flow:

flowchart TD
    A["Mail from external to MX"] --> B["Sender = accepted domain?"]
    B -->|"No"| G["Normal mail flow"]
    B -->|"Yes"| C["Authentication present?"]
    C -->|"Yes"| G
    C -->|"No"| D["Reject Direct Send enabled?"]
    D -->|"No"| G
    D -->|"Yes"| E["Mail rejected"]

Figure: How Exchange Online decides whether Reject Direct Send applies.

The change takes effect immediately. In the tenants where I've used it, it does stop internal-looking phishing at the edge.

I recommend enabling it now, after careful preparation

For Exchange domains, I think Reject Direct Send is the most practical anti-phishing improvement in years. It closes a gap that SPF, DKIM and DMARC were never built to handle on their own. Preparation still matters, though. Find every Direct Send source, migrate it, and only then turn the setting on. If you're unsure how your devices are configured or want to roll out SMTP AUTH safely, my post SMTP AUTH basic authentication: Exchange Online ends it has practical steps and licensing notes. It's not often that the most secure option is also the simplest one, and here it is, once you've done some detective work up front.