Immediate answer
Discover first, authorize deliberately, then reject.
RejectDirectSend is an Exchange Online organization setting for rejecting anonymous messages whose SMTP envelope sender uses one of the tenant's accepted domains when the message is not attributed to an inbound connector.
That is narrower than “block every message sent directly to the tenant MX endpoint.” Ordinary internet mail from other domains and mail attributed to an authorized connector are different cases. A safe rollout begins by identifying legitimate Direct Send traffic and assigning each sender an authenticated or connector-attributed replacement.
Precise vocabulary
Direct Send is not every connection to Exchange Online port 25.
Microsoft defines Direct Send around anonymous mail that uses the organization's own accepted domain and targets recipients in that organization. The relevant sender is the P1 SMTP envelope address—not merely the visible header From value.
| Path | Identity | Effect of RejectDirectSend |
|---|---|---|
| Direct Send | Anonymous; accepted-domain envelope sender; no connector attribution | Rejected when the setting is enabled |
| Connector SMTP relay | Attributed through a matching certificate or configured source IP | Not the anonymous Direct Send path when attribution succeeds |
| SMTP client submission | Authenticated submission, normally on port 587 | Separate authenticated path |
| External internet sender | Another domain sending inbound mail | Not Direct Send merely because it reaches the Exchange Online endpoint |
Messages sent from subdomains can also be affected when the accepted-domain configuration matches subdomains. Review envelope domains and tenant accepted-domain settings before enforcement.
Security control
RejectDirectSend makes an implicit path explicit.
Without this control, anonymous systems can submit messages that appear to originate from an accepted domain and target mailboxes inside the tenant. SPF, DKIM, DMARC, anti-spam signals, and transport rules remain important, but they do not provide the same tenant declaration that anonymous same-domain Direct Send is unwanted.
Microsoft documents Set-OrganizationConfig -RejectDirectSend $true as the organization setting. Changing it requires the appropriate Exchange organization-configuration role. Do not enable it as a blind hardening toggle: printers, applications, monitoring systems, third-party services, and forgotten workflows may currently depend on Direct Send.
An intended connector path can still be rejected if Exchange does not attribute the message to that connector. Test with message trace details and confirm the connector name rather than assuming that a configured connector matched.
Change evidence
Use the Change Optics DRS scenario as a discovery source.
Microsoft's Change Optics Report is available in the Exchange admin center under Reports → Mail flow. The DRS scenario surfaces sample messages with the characteristics expected to be affected by RejectDirectSend. The report can be filtered and its detail data exported for investigation.
It is a change-impact aid, not a permanent complete inventory guarantee. Correlate it with message trace, Defender evidence where licensed, application ownership, firewall or flow logs, and device configuration. A quiet report cannot prove that a quarterly job or dormant emergency device does not exist.
- 01
Export the DRS examples
Group by source, envelope sender, recipient, time, and responsible system.
- 02
Verify business ownership
Do not whitelist unidentified traffic merely because it currently delivers.
- 03
Choose a supported replacement
Use native OAuth, connector attribution, an internal-only service, or a controlled compatibility bridge according to the workload.
- 04
Observe the reduction
Confirm the old anonymous path disappears before enforcing rejection.
Staged enforcement
Move legitimate senders without creating broad exceptions.
Native modern authentication
Prefer the vendor-supported Microsoft OAuth path when the exact device or application version provides it.
Certificate or IP connector
Use connector attribution when the mail server can present an accepted-domain certificate or has a suitable exclusive static public IP and outbound port 25.
Transport-rule transition
Where Microsoft documents it as appropriate, quarantine or redirect suspect same-domain anonymous traffic while tightly controlling explicit exceptions. Treat this as policy design, not a substitute for sender identity.
Local compatibility service
For legacy clients, accept only authorized local sources and create a separate authenticated Microsoft-facing connection.
Test internal and external recipients, connector attribution, sender domains, subdomains, third-party services, failure visibility, and rollback. Keep the change record and named owner for every exception.
Product boundary
RelayBridge uses a different Microsoft-facing path.
RelayBridge accepts SMTP from explicitly configured local clients and submits to Exchange Online through OAuth-authenticated SMTP client submission over TLS on port 587. That Microsoft-facing connection is not anonymous Direct Send and does not require an inbound connector.
This can give selected legacy senders a migration path before Direct Send is rejected. It does not discover every Direct Send dependency, configure RejectDirectSend, or change tenant mail-flow policy on the administrator's behalf.
Clarifications
Frequently asked questions.
Does RejectDirectSend block all mail sent to our MX endpoint?
No. The control targets anonymous messages using an accepted-domain envelope sender without connector attribution. Microsoft distinguishes that from ordinary external inbound mail and properly attributed connectors.
Is SPF enough to secure Direct Send?
No single control should be treated as sufficient. SPF contributes sender-domain evidence, but RejectDirectSend provides an explicit tenant policy for the anonymous same-domain path.
Can we enable the setting if Change Optics is empty?
An empty DRS view is useful evidence but not proof that no infrequent workflow exists. Reconcile additional logs and system ownership, then use a controlled change and rollback plan.
Authoritative sources