Exchange Online Direct Send Troubleshooting (2026): Reject Direct Send, 5.7.68 NDR Fixes & Connector Migration

Updated: July 30, 2026

Reject Direct Send is a per-tenant Exchange Online setting that, when enabled, blocks any anonymous message arriving at your MX endpoint that claims to be from one of your own accepted domains. The sending host is rejected with 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. In early 2026 Microsoft is flipping the default to True for newly created commercial tenants, so multifunction printers, scanners, ERP jobs, and monitoring tools that quietly used Direct Send for years will start bouncing unless you migrate them onto a partner inbound connector first.

I hit this one the hard way on a Friday afternoon rollout last quarter (a fleet of Kyocera MFPs that had been happily scanning-to-email for six years just stopped, silently, the moment we spun up a new tenant for a spin-off business unit). So, if you're staring at a 5.7.68 NDR right now, you're in the right place.

• What flipped: Set-OrganizationConfig -RejectDirectSend $true is now the default for new commercial tenants provisioned from early 2026. Existing tenants keep $false, but you should still plan the migration.
• The NDR to memorize: 550 5.7.68 TenantInboundAttribution means an unauthenticated sender used your own domain in the envelope From (P1). SPF passing isn't enough; the traffic still needs connector attribution.
• Fix path: create an Exchange Online partner inbound connector authenticated by static public IP or by certificate CN/SAN before you turn Reject Direct Send on.
• Audit first: the new Direct Send report in the Exchange admin center (Change Optics) surfaces every anonymous domain-matching sender for the last 30 days. Run it before enabling enforcement.
• Break glass: disabling takes up to 30 minutes to propagate globally, so do it during the maintenance window, not while a printer queue is on fire.
• Scope exceptions: Reject Direct Send is currently not offered in GCC-High, DoD, or US Sovereign clouds. Those tenants keep unauthenticated Direct Send indefinitely.

What is Direct Send in Exchange Online?

Direct Send is the anonymous SMTP path that lets a device or service on the internet drop a message straight onto your tenant’s MX endpoint at <tenant>.mail.protection.outlook.com over TCP 25, using an envelope From (P1 sender) that matches one of your accepted domains. There is no authentication, no connector, and no license attached to the sender. Exchange Online treats it the same way it treats any inbound internet mail, then delivers it to internal recipients because the recipient domain is hosted in the tenant.

Historically this was the default recommendation for multifunction printers, scanners, backup software, ticketing systems, and other “scan-to-email” style workloads that couldn’t perform modern authentication. It worked as long as SPF on your domain listed the public IP of the device, and it required zero credential hygiene. That convenience is exactly what made it the number-one internal spoofing vector: an attacker with an open port 25 anywhere on the internet could look up your MX record, send a message from [email protected] to [email protected], and land it in the inbox. SPF alone rarely enforces enough to stop that.

Direct Send is not the same as SMTP client submission (authenticated port 587 with a mailbox credential), nor is it the same as an inbound relay connector (unauthenticated port 25 but scoped to a static public IP that you own). Confusing those three is where most of the follow-on NDRs come from, so pin the distinction down before you start moving devices.

What changed in 2026: Reject Direct Send as the new default

Microsoft introduced the RejectDirectSend parameter on Set-OrganizationConfig in mid-2025 as an opt-in preview, then began rolling it forward as a default. Starting in early 2026, any newly provisioned commercial Exchange Online tenant is created with RejectDirectSend = $true out of the box. Existing tenants are unchanged (the flag stays $false), but Microsoft has signaled that a future enforcement wave will apply the same default to tenants that haven’t opted out. Treat the current state as a migration window, not a permanent reprieve.

When the flag is $true, Exchange Online rejects any message where all three of the following are true at the front door: the connection is anonymous (no partner or on-prem connector matched), the envelope From (P1 MAIL FROM) uses an accepted domain, and the recipient is a mailbox in the same tenant. That’s precisely the Direct Send pattern, and it’s precisely the internal-spoof pattern. The rejection happens before SPF, DKIM, DMARC, and connection filtering are evaluated for delivery decisions, so the sender simply gets the 5.7.68 NDR and the message never reaches EOP for content scanning.

Two scope caveats matter for helpdesk planning. First, Microsoft has stated the setting is not being offered in GCC-High, DoD, or USNat/USSec environments; if your tenant lives in one of those clouds, keep your existing Direct Send configuration and ignore the 2026 default. Second, disabling and re-enabling the flag can take up to 30 minutes to propagate to every Microsoft frontline server, so treat every toggle as a scheduled change, not a real-time control.

How do I fix the 550 5.7.68 TenantInboundAttribution NDR?

The literal NDR body is 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. That single line encodes three separate facts: it was rejected inbound (5.7.x is a policy-class rejection), Exchange Online attributed the mail to your tenant based on the envelope domain match, and no authenticated path was found. Fixing it is a decision tree, not a single command.

1. Confirm the sender is legitimate. Pull the sender IP from the NDR’s Received: chain or from the message trace. If you don’t recognize the IP, do not whitelist it. It’s either a compromised device or an outright spoof attempt.
2. Check whether the source can authenticate. If the printer, LOB app, or SaaS supports SMTP AUTH on port 587, migrate it to authenticated submission with a licensed shared mailbox. That’s the cleanest long-term fix and avoids the connector maintenance burden entirely.
3. If the source can’t authenticate, create a partner inbound connector that maps the source’s static public IP (or its client certificate CN) to your tenant. See the migration section below for the exact PowerShell.
4. Verify with a live send. After the connector is saved, generate a test scan-to-email and confirm the message trace shows the connector name in the Connector column instead of <anonymous>. That’s the definitive proof that attribution now succeeds.

Two anti-patterns to avoid. Don’t extend the SPF record to solve the NDR, because SPF alignment is checked after the connector attribution decision, so a fatter SPF record does nothing to change the 5.7.68 outcome. And don’t create an inbound connector that matches * as the sender domain with a wide public IP range; the connector must be narrowly scoped or you have just re-opened the spoofing hole that Reject Direct Send is designed to close.

Audit Direct Send traffic before you flip the switch

The single most common self-inflicted outage on this migration is enabling RejectDirectSend without knowing what you were relying on it for. Microsoft ships a dedicated Direct Send report inside the Exchange admin center under the Change Optics dashboard that lists every anonymous inbound message from the last 30 days where the P1 sender matched one of your accepted domains. Export the CSV, group by sender IP, and you have your migration backlog.

If you prefer PowerShell (and you should, because the EAC UI truncates after a few thousand rows), run a message-trace pass and filter on the null connector. Sign in with Connect-ExchangeOnline first, then:

# Pull the last 10 days of inbound direct-to-tenant traffic and surface anonymous senders
$start = (Get-Date).AddDays(-10)
$end   = Get-Date

$trace = Get-MessageTraceV2 -StartDate $start -EndDate $end -PageSize 5000 |
    Where-Object { $_.Status -in 'Delivered','Resolved','Expanded' }

$myDomains = (Get-AcceptedDomain).DomainName

$directSend = $trace | Where-Object {
    $sender = $_.SenderAddress
    $domain = ($sender -split '@')[-1]
    $myDomains -contains $domain            # From uses an accepted domain
} | Select-Object Received, SenderAddress, RecipientAddress, FromIP, Subject

$directSend | Group-Object FromIP |
    Select-Object Count, Name |
    Sort-Object Count -Descending |
    Format-Table -AutoSize

What you’re looking for is a small, stable set of source IPs. If the top of the list is your on-prem print server, your Kyocera or Xerox fleet public NAT, and your ERP outbound relay, you’re in good shape; those three connectors will cover most of the traffic. If the list is a long tail of one-hit-wonder IPs from residential ISPs and cloud provider ranges, you’re almost certainly looking at spoofing attempts that Reject Direct Send will silently kill for you, and there is nothing to migrate.

Migrate printers and LOB apps to a partner inbound connector

A partner inbound connector is the supported way to keep unauthenticated devices sending mail through Exchange Online after Reject Direct Send is on. The connector tells EOP: “when you see a message arrive from this IP (or bearing this client certificate), attribute it to my tenant even though it is anonymous SMTP.” That attribution is what makes the 5.7.68 check pass.

You can create it in the EAC (Mail flow → Connectors → Add, choose Partner → Office 365 and pick verification by sender IP), but the reproducible way is PowerShell:

# Connect first
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false

# Create the connector: match by static public IP, scoped to your accepted domain
New-InboundConnector `
    -Name           "MFP-DirectSend-HQ" `
    -ConnectorType  Partner `
    -SenderDomains  contoso.com `
    -SenderIPAddresses 203.0.113.24, 203.0.113.25 `
    -RestrictDomainsToIPAddresses $true `
    -RequireTls     $true `
    -TlsSenderCertificateName $null `
    -Confirm:$false

The two flags that matter for security are -RestrictDomainsToIPAddresses $true (mail from your domain is only accepted if it came from the listed IPs, which is what actually closes the spoofing hole) and -RequireTls $true (forces STARTTLS on the incoming SMTP session, blocking cleartext relay). If your device fleet can’t do TLS 1.2, either update firmware or route through a local on-prem relay that can. Don’t disable TLS on the connector.

Certificate-based attribution is the more resilient option when you can’t pin down a static IP, which is common with cloud-hosted LOB apps behind a load balancer with a changing egress pool. Provision a certificate whose subject or SAN matches a name you control (for example relay.contoso.com), install it on the sending host, and reference it on the connector:

New-InboundConnector `
    -Name           "LOB-App-CertRelay" `
    -ConnectorType  Partner `
    -SenderDomains  contoso.com `
    -TlsSenderCertificateName "relay.contoso.com" `
    -RequireTls     $true `
    -RestrictDomainsToIPAddresses $false `
    -Confirm:$false

Point the device at your tenant’s MX endpoint (contoso-com.mail.protection.outlook.com) on port 25, send a test message, and confirm the message trace attributes it to the connector name. For MFP-specific gotchas around firmware TLS defaults, SNMP polling collisions, and driver hell, the printer troubleshooting guide has the deeper playbook.

SMTP AUTH vs Direct Send vs SMTP relay: which one to use

The three Microsoft 365 outbound-from-device methods look similar on paper and behave very differently under Reject Direct Send. Pick deliberately:

Dimension	SMTP AUTH (client submission)	Direct Send	Partner inbound connector (SMTP relay)
Port & endpoint	587, smtp.office365.com	25, <tenant>.mail.protection.outlook.com	25, <tenant>.mail.protection.outlook.com
Authentication	Modern auth / OAuth 2.0 client credentials	None (anonymous)	Sender IP or client TLS certificate
Recipients allowed	Internal + external	Internal only (own tenant)	Internal + external
License required	Yes; a mailbox with SMTP AUTH enabled	No	No
Blocked by RejectDirectSend	No (authenticated)	Yes (5.7.68 NDR)	No (connector attribution)
Best for	Modern LOB apps that can do OAuth or app passwords	Legacy internal-only scan-to-self	MFPs, ERP, monitoring, scan-to-anywhere
Failure mode when misconfigured	AUTH LOGIN failure, MFA prompt loop	5.7.68 anonymous rejection	5.7.64 relay denied, 5.7.708 IP not on connector

The short rule: if the device can authenticate, use SMTP AUTH. If it can’t authenticate and only sends to internal recipients, Direct Send used to be fine but is being deprecated by default, so migrate it to a partner connector too. If it can’t authenticate and needs to reach external recipients, a partner connector is your only supported option. Note that SMTP AUTH itself is being retired from new tenants and is only enabled at the mailbox level on legacy tenants. The SMTP basic auth retirement migration guide covers that trajectory in detail.

Why SPF, DKIM, and DMARC were not enough

Every response to the original Direct Send spoofing vulnerability in the community was a variant of “just publish a strict SPF and DMARC record.” It sounds right, and it isn’t enough, for reasons that took Microsoft years to acknowledge. SPF only fails a message; it does not block it unless the receiver chooses to. DMARC only enforces alignment if it is honored, and Exchange Online has quirks that make honoring inconsistent.

The specific loophole is the Spam Confidence Level. Any message that has been assigned SCL:-1 (“trusted”, typically because a connector, a mail flow rule, or a spoof intelligence entry marked it that way) bypasses spam filtering and, in many configurations, DMARC evaluation as well. Attackers who found a misconfigured “bypass spam filtering” connector could drop spoofed mail into a mailbox even when the domain published p=reject. Reject Direct Send closes that class of bug at the front door: the message is rejected on the SMTP session before any SCL stamping happens.

None of that means SPF, DKIM, and DMARC are optional. They still matter for outbound deliverability, for detecting spoofing at other receivers, and for authenticated Direct Send scenarios where your printer IPs are in your SPF record and should legitimately pass. The point is that they are complementary controls, not substitutes. Microsoft’s Introducing more control over Direct Send blog post is the primary reference for how the new setting interacts with the existing anti-spoof stack.

Break-glass: temporarily re-enable Direct Send

If enforcement lands during business hours and a critical workflow starts bouncing (the classic case is the loading-dock BOL printer that emails signed manifests to a customer), you need a fast rollback. The command is short:

# Sign in as a Global Admin or Exchange Admin
Connect-ExchangeOnline -ShowBanner:$false

# Confirm current state
Get-OrganizationConfig | Format-List RejectDirectSend

# Roll back
Set-OrganizationConfig -RejectDirectSend $false

# Verify (immediate) and warn the caller
Get-OrganizationConfig | Format-List RejectDirectSend
Write-Warning "Propagation to all frontline servers can take up to 30 minutes."

Two important behaviors to expect. First, propagation is asynchronous. The setting change is committed to the tenant config immediately, but individual Microsoft frontline SMTP servers can take up to 30 minutes to see the update. Don’t tell the printer vendor you rolled back at 14:02 and expect the retry queue to clear at 14:03. Second, this is a global tenant setting. There is no per-domain or per-connector opt-out. Once you disable it, every anonymous same-domain sender is accepted again, including any spoofing attempts that had been correctly blocked. Plan to re-enable within the same maintenance window once you have created the missing connector.

Related NDR codes you will see nearby (5.7.64, 5.7.708, 5.7.23)

Reject Direct Send is one of a family of policy-class NDRs that show up during any Exchange Online mail-flow migration. Learn to distinguish them so you fix the actual problem rather than looping through the wrong runbook:

• 550 5.7.64 TenantAttribution; Relay Access Denied: the connector matched by IP but the sender domain is not an accepted domain on your tenant. Fix by adding the domain, or by scoping the connector correctly. Typical root cause: certificate name change after a firmware update.
• 550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP: your public IP is on a Microsoft-managed block list, or the source IP changed after an ISP re-NAT and no longer matches the connector. Fix by updating the connector -SenderIPAddresses, and separately by requesting delisting via the Microsoft Smart Network Data Services delisting portal if the IP shows as blocked.
• 550 5.7.23 The message was rejected because of Sender Policy Framework violation: the sender domain publishes an SPF record and the sending IP is not in it. This is a genuine SPF failure and is unrelated to Direct Send, but it often surfaces on the same devices because admins reach for SPF as the fix and misconfigure it. Adjust SPF, or add the IP to SPF and retry.
• 550 5.1.8 Access denied, bad outbound sender: the mailbox used to send has been restricted (usually by anti-spam policy) after sending too much or being flagged as compromised. Not a Direct Send issue; investigate the mailbox itself.

For a broader map of Exchange Online NDR classes and how to trace them end-to-end, the updated Exchange Online SMTP relay requirements and Microsoft’s printers, scanners, and LOB applications guide are the two authoritative starting points. Cross-check DNS (MX, SPF, DKIM CNAMEs, DMARC TXT) using the workflow in the DNS troubleshooting guide before you assume the problem lives in Exchange.

Frequently Asked Questions

Will Reject Direct Send break my existing printers overnight?

Only if you enable it without a partner inbound connector. On existing commercial tenants the default remains $false, so your printers keep working until you actively run Set-OrganizationConfig -RejectDirectSend $true. Newly provisioned tenants in early 2026 start with the flag on, so if you spin up a new tenant this year you must build the connectors before you cut printers over.

How do I check whether Reject Direct Send is enabled on my tenant?

Run Get-OrganizationConfig | Format-List RejectDirectSend after connecting with Connect-ExchangeOnline. The output shows True or False. This is a global tenant setting, so there is no per-user or per-domain view of it.

Does adding my printer’s IP to my SPF record fix the 5.7.68 NDR?

No. Reject Direct Send is evaluated before SPF, and the check is about whether Exchange Online can attribute the traffic to your tenant via a connector, not whether SPF passes. A fatter SPF record is invisible to this rejection. Create a partner inbound connector scoped to that IP instead.

What is the difference between Direct Send and SMTP relay in Microsoft 365?

Direct Send is unauthenticated port 25 to your tenant MX, restricted to internal recipients, with no connector involved. SMTP relay is unauthenticated port 25 to your tenant MX but attributed via a partner inbound connector that matches sender IP or client TLS certificate. It can reach external recipients, and it survives Reject Direct Send. Same protocol, different attribution model.

Is Reject Direct Send available in GCC-High or DoD tenants?

No. Microsoft has stated the setting is not currently offered in GCC-High, DoD, or USNat/USSec environments. Sovereign-cloud tenants keep the legacy Direct Send behavior for now, so plan for it to change eventually, but don’t build automation that assumes the flag exists.

Can attackers still spoof my domain after I enable Reject Direct Send?

They can’t use the anonymous Direct Send path against your own tenant (that specific loophole is closed). They can still attempt to deliver spoofed mail to other receivers, which is why you should keep DMARC set to p=reject with alignment, keep DKIM signing every outbound stream, and keep SPF accurate for every legitimate sender.