Closing Direct Send Without Silencing the Scanners

Direct Send was never meant to be clever. It exists so that a scanner or a small application can drop mail straight onto your tenant's MX endpoint, with one of your own addresses as the sender, without signing in anywhere. Microsoft describes it as something that "mimics incoming anonymous emails from the internet, apart from the sender domain", which is a polite way of saying that the only thing telling your scanner apart from anyone else on the internet is the address it claims to have.

In May 2025 someone put that to use. Varonis traced a campaign that reached more than 70 organizations, most of them in the US, with mail that looked internal because, as far as Exchange Online could tell, it was. One line of PowerShell against the tenant's smart host, the victim's own address as the sender, and a PDF with a QR code leading to a fake Microsoft sign-in page. The lures were missed-call and fax notifications, the kind of mail a multifunction device sends every day, which is precisely why nobody thought twice.

The Switch Microsoft Added

Since April 2025 there's a real off switch, and it's one line:

Set-OrganizationConfig -RejectDirectSend $true

It takes effect within about half an hour. From then on, anonymous mail that uses one of your domains in the envelope sender gets turned away at the door, unless it comes in over an inbound connector you've configured, and whoever sent it sees this:

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

Microsoft has also said it wants this on by default for new tenants, and that those tenants won't be able to turn it off. The direction is clear, even if the date isn't.

Find Out Who Is Using It First

Most tenants haven't flipped the switch yet for one simple reason: nobody knows what else goes quiet when they do. Microsoft suggests starting with your SPF record, because whatever sends through Direct Send without being listed there already has trouble getting delivered. For the actual traffic, the Change Optics report, which Microsoft released as a preview in the Exchange admin center, shows example messages the setting would reject. A historical message trace for everything received without a connector goes back up to 90 days:

Start-HistoricalSearch -ReportTitle "Direct Send" -ReportType ConnectorReport `
  -ConnectorType NoConnector -Direction Received `
  -StartDate (Get-Date).AddDays(-89) -EndDate (Get-Date) `
  -NotifyAddress admin@contoso.com

If you have Defender for Office 365 Plan 2, Advanced Hunting finds the same mail in EmailEvents where the connector field is empty. One thing to know before you read the results: these reports work best when your MX points to a gateway that comes in over its own connector. If your MX points straight at Exchange Online, all your ordinary inbound mail arrives without a connector as well, and you'll want to filter for your own domains as the sender.

What turns up is rarely a surprise, just a longer list than expected: the copiers, a building management system, a label printer in the warehouse, and every now and then a cloud service that sends invoices in your name. If you'd like to see the effect before you commit, Microsoft's own middle ground is a mail flow rule that quarantines this kind of mail instead of rejecting it. You lose nothing, and a week later you know exactly what the switch would have stopped.

Moving the Scanners Out of the Way

Microsoft's answer for legitimate senders is an inbound connector of type Partner that trusts your office's public IP address, or a certificate, which few scanners have in practice. It costs nothing, and for a single site with a static address it works. The small print: the address must not be shared with anyone outside your organization, every site with its own internet breakout needs its own entry, and the IP address becomes the only key. Anything behind it can send as anyone in your domain, including the laptop in accounting that clicked on the wrong fax notification.

Devices that can sign in and only ever mail colleagues can move to High Volume Email, which we looked at in the post on SMTP AUTH. The rest were on Direct Send in the first place because they can't do TLS or a login, and they need a relay that accepts what they can do and still decides who may send as whom.

What to Do This Week

1. Run the no-connector message trace, open the Change Optics report, and write down every source you find.
2. Give the legitimate ones a proper path: a partner connector for known IP addresses, High Volume Email for devices that only mail internally, a relay for the rest.
3. Put a quarantine rule in place for a week and look at what lands there.
4. Then set RejectDirectSend and keep an eye on 5.7.68 bounces for a few days.

We built Sendman as that relay. The scanner signs in, or sends from an address range you allow, and it may send as scan@contoso.com but not as your CEO.

Sources

• Microsoft Exchange Team: Introducing more control over Direct Send in Exchange Online, April 28, 2025, updated since
• Microsoft Exchange Team: Direct Send vs sending directly to an Exchange Online tenant, August 4, 2025
• Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
• Varonis Threat Labs: Ongoing Campaign Abuses Microsoft 365's Direct Send to Deliver Phishing Emails, June 26, 2025