What does RejectDirectSend block?

It rejects anonymous messages sent to your mailboxes when the envelope sender (P1 MAIL FROM) domain is one of your accepted domains and the message isn't attributed to an inbound connector that matches the sender IP or certificate. The P2 From header isn't checked, and spoofing of other organizations' domains is still handled by the normal anti-spoofing protections.

What error do blocked senders get?

Senders receive 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. To allow a legitimate sender, create a partner inbound connector that matches its certificate or static IP addresses, or turn the setting off again.

Does RejectDirectSend lock my tenant to a third-party mail gateway?

No. It only acts on mail that uses your own accepted domains as the envelope sender. To make Exchange Online accept mail only through a gateway your MX points to, create a partner inbound connector with RestrictDomainsToCertificate or RestrictDomainsToIPAddresses set to true.

How long does it take for RejectDirectSend to apply?

Microsoft says the change should propagate across the service within 30 minutes. Changing it requires an administrator with the Organization Configuration role.

Reject Direct Send in Exchange Online Safely

To block spoofed Direct Send mail in Exchange Online without breaking legitimate senders, first find every device, application and service that sends anonymously from your own domain, give each approved one a partner inbound connector that matches its static IP address or TLS certificate, and only then run Set-OrganizationConfig -RejectDirectSend $true. After that, anonymous messages that use one of your accepted domains as the envelope sender and aren't attributed to a connector are rejected with 550 5.7.68. The reports and connector settings below let you do this in a controlled order.

Who this is for and what you will have

This guide is for Exchange Online administrators who want to close the path attackers use to send mail that appears to come from inside the organization, but who still have multifunction printers, line-of-business applications or SaaS platforms delivering mail from the company domain. At the end you will have:

An inventory of the Direct Send traffic arriving in your tenant, from the Change Optics report and connector reports.
A partner inbound connector for each approved sender, authenticated by certificate or static IP.
RejectDirectSend enabled and verified with message trace.
A fallback plan for senders that have neither a static IP nor a dedicated certificate.

What Direct Send is and what the setting blocks

Direct Send is anonymous delivery straight to your tenant's MX endpoint (for example contoso-com.mail.protection.outlook.com) using an address in one of your accepted domains. It needs no authentication, which is why it is easy for a scanner and also easy for an attacker. Microsoft's own guidance says most customers don't need it and recommends it only when a device or app can't use client submission or an SMTP relay connector. Direct Send can only reach mailboxes in your tenant; mail to external recipients is rejected.

RejectDirectSend is an organization setting. When it is $true, Exchange Online rejects anonymous messages sent from your domain to your mailboxes when both of these are true:

The message doesn't match an inbound connector. Only inbound connectors configured to match the sender IP address or certificate are considered.
The domain in the envelope sender (the P1 MAIL FROM, or 5321.MailFrom address) is an accepted domain in your organization.

Points that matter when you plan:

Behavior	Detail
Default	`False` (opt-in)
Header checked	Envelope sender only; the P2 From header isn't checked
Subdomains	Covered when the accepted domain has "Accept mail for all subdomains" (`MatchSubDomains`) enabled
Propagation	Within 30 minutes
Error returned	`550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources`
Permission	The Organization Configuration role
Clouds	Not enabled for GCC High, DoD and USNat/USSec at the time of Microsoft's announcement
MX location	Works whether your MX points to Exchange Online or to a third-party service

Microsoft introduced the setting as a public preview and has said it plans to enable it by default for new tenants, without the ability to turn it off. Spoofing of domains you don't own is not Direct Send and is still handled by the standard anti-spoofing protections.

Prerequisites

Exchange Online PowerShell with the ExchangeOnlineManagement module, and an account with the Organization Configuration role.
Access to Reports in the Exchange admin center.
Your domains' SPF records. Microsoft suggests them as the place to start when you look for Direct Send senders.
The public IP addresses of your offices and data centers, and contact details for SaaS vendors that send as your domain.

Check the current setting:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-OrganizationConfig | Format-List RejectDirectSend
Get-AcceptedDomain | Format-Table DomainName,MatchSubDomains
Get-InboundConnector | Format-Table Name,ConnectorType,Enabled,RestrictDomainsToIPAddresses,RestrictDomainsToCertificate

Step 1: Find the Direct Send traffic you would block

Change Optics report

Microsoft added a report to show messages that future changes would affect. In the Exchange admin center go to Reports > Mail flow > Change Optics Report. Its DRS scenario represents Direct Send traffic received by your tenant. The Summary page charts the volume, and the Details page shows example messages for the selected scenario, which you can export. Use message trace to get more detail about any example message. Microsoft released the report as a public preview in April 2026.

Messages received without a connector

A historical search returns inbound messages that were not received through any connector, for up to the last 90 days:

Start-HistoricalSearch -ReportTitle "NoConnectorInbound" `
  -StartDate 09/01/2026 -EndDate 10/10/2026 `
  -ReportType ConnectorReport -ConnectorType NoConnector `
  -Direction Received -NotifyAddress admin@contoso.com

The same data is available in the Inbound messages report under Reports > Mail flow. If your MX points directly to Exchange Online, this view includes all ordinary internet mail, so filter for sender addresses in your own domains.

Advanced hunting

With Microsoft Defender for Office 365 Plan 2, this query counts inbound messages that arrived without a connector, by source IP, over 30 days:

EmailEvents
| where EmailDirection == "Inbound" and Timestamp >= ago(30d)
| where Connectors == "" and isnotempty(SenderIPv4)
| summarize count() by SenderIPv4

Add a filter on SenderMailFromAddress ending in your domains to narrow it to Direct Send candidates. Then cross-check every IP you find against your SPF record and your known office IPs.

Step 2: Classify each sender

Sender	What to do
Printer or app on your network with a static public IP, internal recipients	Partner connector by IP address
SaaS service sending as your domain from a dedicated certificate	Partner connector by certificate (preferred by Microsoft)
App that can sign in and supports OAuth	Move it to client submission with OAuth instead of Direct Send
Device that can store a username and password but not OAuth, internal recipients	Move it to High Volume Email
Vendor without static IPs or a dedicated certificate	Use a mail flow rule fallback, or ask the vendor to move to an authenticated method
Unknown source	Leave it unapproved; it is what the setting is meant to stop

Removing a sender from Direct Send altogether is often simpler than building a connector for it. SMTP AUTH with OAuth client credentials covers applications, and Fix 550 5.7.30 covers High Volume Email and relay connectors for devices.

Step 3: Create partner connectors for approved senders

A partner inbound connector attributes the sender's messages to a connector, so RejectDirectSend no longer treats them as anonymous.

Certificate-based connector

Use this when the sender presents a TLS certificate whose Subject or SAN contains a domain you can name. In this example a SaaS platform, fabrikam.com, sends invoices as contoso.com:

New-InboundConnector -Name "Partner - Fabrikam invoicing" `
  -ConnectorType Partner `
  -SenderDomains contoso.com `
  -TlsSenderCertificateName "*.fabrikam.com" `
  -RestrictDomainsToCertificate $true `
  -RequireTls $true

With RestrictDomainsToCertificate set to $true, mail can use the connector only if the Subject of the certificate presented by the source server matches TlsSenderCertificateName. TlsSenderCertificateName accepts a domain or a wildcard such as *.fabrikam.com, but not an embedded wildcard.

IP-based connector

Use this for devices on your own network that send from a static, unshared public IP address:

New-InboundConnector -Name "Partner - Contoso office scanners" `
  -ConnectorType Partner `
  -SenderDomains contoso.com `
  -SenderIPAddresses 203.0.113.10,198.51.100.0/28 `
  -RestrictDomainsToIPAddresses $true

SenderIPAddresses takes IPv4 addresses or CIDR ranges from /24 to /32; IPv6 isn't supported, and the list only applies when RestrictDomainsToIPAddresses is $true. RequireTls defaults to $true for partner connectors and rejects messages not sent over TLS, so set it to $false only for a device that genuinely can't use TLS.

Understand the side effect before you save it: with RestrictDomainsToIPAddresses set to $true, the connector rejects mail from the domains in SenderDomains when it comes from any IP address not in the list. That is the intended lock, but it means every legitimate anonymous source for contoso.com must be in a connector before you create it.

If the same domain has both IP-based and certificate-based sources, test each one before you rely on the result. Microsoft's documentation doesn't describe how several restricted partner connectors for the same sender domain interact, so confirm every source in message trace (next step) and create connectors in a change window where you can disable one quickly with Set-InboundConnector -Enabled $false.

Don't use SenderDomains * here

Microsoft's examples with -SenderDomains * and a restriction belong to a different scenario: locking down a tenant whose MX record points to a third-party filtering service, so that mail which bypasses the service is rejected. With your MX pointing to Exchange Online, a * connector restricted to a few IPs would reject ordinary internet mail from everyone else.

If your MX does point to a third-party gateway, that lock-down connector is still the recommended configuration, and mail arriving through the gateway is attributed to it. RejectDirectSend doesn't lock your tenant to the gateway on its own.

Step 4: Confirm attribution, then enable

Ask each approved sender to send a test message, wait for trace data to populate, and check that the message was attributed to the new connector:

Get-MessageTraceV2 -MessageId "<test-message-id@contoso.com>" | Get-MessageTraceDetailV2 | Format-List

The connector name appears in the trace detail. You can also see the connector's GUID on the email entity page in Microsoft Defender. When every approved sender is attributed, enable the setting:

Set-OrganizationConfig -RejectDirectSend $true
Get-OrganizationConfig | Format-List RejectDirectSend

Allow up to 30 minutes for it to apply across the service. To roll back, set the value to $false.

Fallback for vendors without IPs or certificates

If a vendor that must send as your domain has neither static IP ranges nor a dedicated certificate, Microsoft suggests leaving RejectDirectSend off and using a mail flow rule that quarantines or redirects Direct Send traffic instead, with an exception for that vendor, such as a unique X-header it stamps on its messages. The rule logic is: if the message is received from outside the organization and the sender domain is contoso.com, deliver it to hosted quarantine, except if the message header contains the vendor's header and value. A rule is more flexible but less strict than the organization setting, so treat it as temporary and keep pressing the vendor for an authenticated method.

Verify after enabling

Send a test message from each approved device and service and confirm delivery.
Ask someone outside your network to send a message to an internal mailbox with a contoso.com envelope sender through your MX endpoint. It should be rejected: with 5.7.68 from RejectDirectSend, or earlier by a restricted partner connector if contoso.com is in its SenderDomains.
Re-run the Change Optics report and the no-connector search over the following weeks. Remaining Direct Send traffic from your domains should now be rejected attempts, not deliveries.
Keep the connector inventory current. A new office IP or a renewed vendor certificate with a different subject is the most likely cause of a future rejection.

Troubleshooting

A printer started bouncing after you enabled the setting or created a connector. Its public IP isn't in a partner connector, or it changed. If the NDR shows 5.7.68, RejectDirectSend rejected it; a different rejection code points to a restricted partner connector or another control, so check the message trace detail. Check the source IP in message trace and update SenderIPAddresses with Set-InboundConnector, or move the device to High Volume Email or an SMTP relay connector.

A SaaS sender is rejected even though a certificate connector exists. The certificate Subject the service presents doesn't match TlsSenderCertificateName, or the service delivered without TLS. Ask the vendor for the exact certificate name and confirm it uses TLS.

Messages that colleagues sent to an external party come back rejected. This is Microsoft's documented known issue. When a third party forwards a message from your user back to your organization and its provider doesn't use Sender Rewriting Scheme (SRS), the message returns with your user's address as the sender and is treated as Direct Send. Those messages were already failing SPF before; with the setting on, they are rejected unless a partner connector covers the forwarding source.

Mail from a subdomain is rejected. The parent accepted domain has MatchSubDomains enabled, which brings subdomains into scope. Add the subdomain to the connector's SenderDomains (wildcards such as *.contoso.com are supported) and to its IP or certificate restriction.

Internet mail stopped arriving after you created a connector. Check for a partner connector with SenderDomains * and a restriction. Unless your MX points to a third-party gateway that the connector matches, disable it.

Checklist

Change Optics report (DRS) and a no-connector historical search reviewed for your own domains.
Every Direct Send source classified: connector, move to an authenticated method, or block.
Certificate-based partner connectors created where the sender has a dedicated certificate; IP-based ones only for static, unshared IPs.
No restricted SenderDomains * connector unless your MX points to a third-party gateway.
Test messages attributed to the right connector in message trace.
RejectDirectSend set to $true and verified with an unauthorized test.
SPF, DKIM and DMARC configured for every domain that still has an approved anonymous sender.

Reject Direct Send in Exchange Online without breaking printers and apps