What this check looks at
Checks that Exchange Online rejects Direct Send: unauthenticated mail sent straight to the tenant’s mail servers using one of its own domains as the sender.
Direct Send delivers mail to Microsoft 365 without signing in: a device or application connects to the tenant’s MX endpoint (such as contoso-com.mail.protection.outlook.com) on port 25 and hands over a message addressed to someone in the organisation, using one of the organisation’s own domains as the sender. It is meant for printers, scanners and line-of-business apps, and Exchange Online accepts it by default.
The check reads the RejectDirectSend setting in Exchange Online’s organisation configuration, which Microsoft added in 2025. It passes when the setting is on, so unauthenticated messages using the organisation’s domains that do not arrive through a connector are rejected, and fails when it is off.
Anyone on the internet can use Direct Send: no account, no password, only the tenant’s MX host name, which is public. Phishing campaigns in 2025 used it at scale to deliver messages that appear to come from colleagues or internal systems, such as voicemail notifications and scanned documents, which people trust because they look internal. SPF and DMARC catch some of it, but many tenants’ settings let it through.
Why it matters
Direct Send lets anyone on the internet deliver mail that appears to come from inside the organisation, without signing in. Phishing campaigns abuse it to send convincing "internal" messages; rejecting it stops them once devices that need to send use a connector.
A member of staff receives a voicemail notification, apparently from a no-reply address on the company’s own domain, with a link to play the message. It came by Direct Send from a server abroad, but it looks exactly like the phone system’s real notifications. One click on a fake sign-in page and the attacker has a foothold inside the organisation.
Rejecting Direct Send stops that whole class of message at the door. The cost is a one-off piece of work: moving the scanners and applications that use Direct Send to an authenticated route first, so they keep working.
CIS Microsoft 365 Foundations Benchmark 6.5.5 asks for Direct Send submissions to be rejected. NIST CSF 2.0 PR.PS-01, ISO 27001 A.5.14 and A.8.9, CIS Controls v8 4.1 and NCSC CAF B4.b cover closing unauthenticated routes into the organisation.
How to fix it
Before you start
- Find what sends by Direct Send: printers, scanners and apps delivering straight to the tenant’s MX as the organisation’s domain (message trace, unauthenticated inbound from own domains).
- Move each to SMTP AUTH or a partner connector with TLS before the change.
Step by step
- Find the devices and apps that use Direct Send. Check scanners, multifunction printers and applications (finance, CRM, alarm and phone systems) for an SMTP server set to the tenant’s MX host on port 25 with no sign-in. To confirm from Exchange, open a message one of them sent and look in its headers for X-MS-Exchange-Organization-AuthAs: Anonymous with a sender on your own domain, or run a message trace in the Exchange admin centre (admin.exchange.microsoft.com) under Mail flow > Message trace for senders on your domains over the last 10 days and look for messages arriving from outside IP addresses.
- Give each one an authenticated route. For devices at an office with a static public IP address, create an inbound connector in the Exchange admin centre under Mail flow > Connectors > Add a connector, from your organisation’s email server to Office 365, identified by that IP address or by a certificate; the device keeps sending to the same MX host and is now recognised. Otherwise move it to SMTP AUTH submission (Exchange Online’s SMTP endpoint, port 587, a dedicated mailbox with SMTP AUTH allowed for that mailbox only), or move an application to a sending service with its own SPF and DKIM.
- Test each sender you moved. Send a test from each device or application and check it arrives, and that message trace now shows it coming through the connector or as authenticated.
- Reject Direct Send. Connect with Connect-ExchangeOnline and run Set-OrganizationConfig -RejectDirectSend $true. From then on, unauthenticated messages using the organisation’s domains are refused unless they arrive through a connector.
- Watch for anything missed. For the next few days, ask the client to report scans or alerts that stop arriving. A device still using Direct Send gets a 5.7.68 rejection; give it a connector or SMTP AUTH as above.
- Confirm the setting. Run Get-OrganizationConfig | Format-List RejectDirectSend and check it is True. If you can, send an unauthenticated test message from outside the network to the MX host using your own domain as sender; it should be rejected with a 550 5.7.68 error. The next assessment passes.
With PowerShell
Set-OrganizationConfig -RejectDirectSend $true
What users will notice
Unauthenticated mail claiming to be from the organisation’s domains is rejected. Devices still using Direct Send stop delivering until moved.
How to confirm it worked
Get-OrganizationConfig shows RejectDirectSend as True; a test Direct Send message is rejected with a 5.7.68 error.
Frameworks and controls
This check maps to controls in 11 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B4.b Secure configuration |
| DSPT | Standard 9: IT protection |
| NIS2 | Art. 21(2)(g) Basic cyber hygiene practices and training |
| Zero Trust | Applications |
| SOC 2 | CC6.6 Protection against threats from outside the system boundaries |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks |
| ISO 27001:2022 | A.5.14 Information transferA.8.9 Configuration management |
| CIS M365 | 6.5.5 Ensure Direct Send submissions are rejected |
| CIS Controls v8.1 | 4.1 Establish and maintain a secure configuration process (IG1) |
| NIST CSF 2.0 | PR.PS-01: Configuration management practices are established and applied |
| NCSC 10 Steps | Architecture and configuration |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Direct Send: send mail directly from your device or application (Microsoft Learn)