Fixing Exchange Online 550 5.7.68 TenantInboundAttribution Errors and Forwarded Email Quarantine During Cross-Tenant Coexistence
This article explains the root causes and resolutions for forwarded email delivery failures caused by Exchange Online Direct Send protection and email authentication failures.
🔍 The Symptoms / Error Message
⚠️ NDR Received
Forwarded messages were rejected with the following NDR:
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources
⚠️ Additionally — Quarantine Issues
Some forwarded messages were quarantined as SPAM / SPOOF due to:
- SPF failures
- DKIM validation failures
- DMARC failures
- Missing or unrecoverable ARC validation
🧠 Root Cause
Issue 1: Direct Send Protection
💡 Why Exchange Online Rejects the Messages
Exchange Online blocks messages that:
- Use one of the organisation’s accepted domains
- Arrive without trusted authentication
- Do not match a configured Partner Connector
In this scenario, forwarded messages arrived through a third-party SMTP relay and were treated as unauthenticated traffic originating from an accepted domain — triggering the 550 5.7.68 TenantInboundAttribution error.
Issue 2: SPF, DKIM, and DMARC Failures
💡 Why Forwarded Messages Fail Authentication
When messages are forwarded through an intermediary email gateway:
- SPF validation may fail because the connecting server differs from the original sender
- DKIM signatures may become invalid if message headers or content are modified
- DMARC validation subsequently fails due to SPF and DKIM alignment issues
- ARC validation may not be preserved depending on the intermediary platform
As a result, Exchange Online classifies the forwarded messages as spoofed and moves them to quarantine.
🛠️ Step-by-Step Resolution
Resolution 1: Create an Inbound Partner Connector
Configure an Exchange Online Partner Connector in the destination tenant and authenticate incoming messages using the trusted relay IP address.
Exchange Admin Center
Navigate to Mail Flow → Connectors and create a new connector with the following settings:
| Setting | Value |
|---|---|
| From | Partner Organization |
| To | Microsoft 365 |
| Connector Type | Inbound |
| Authentication Method | Verify Sender by IP Address |
| Allowed IP Address | <Trusted Relay Public IP> |
Save and enable the connector.
Verify the Connector via PowerShell
Connect to Exchange Online and confirm the inbound connector is active with the correct IP address.
Connect-ExchangeOnline Get-InboundConnector | Format-List Name,Enabled,SenderIPAddresses
Resolution 2: Create a Transport Rule for Forwarded Messages
Since all legitimate forwarded messages contained a consistent Resent-From header, a mail flow rule was created to reduce the Spam Confidence Level (SCL) and prevent unnecessary quarantine.
Exchange Admin Center
Navigate to Mail Flow → Rules and configure:
| Setting | Value |
|---|---|
| Rule Name | Allow Forwarded Mail |
| Condition | Message Header Includes Any Of These Words |
| Header Name | Resent-From |
| Header Value | @sourcedomain.com |
| Action | Set Spam Confidence Level (SCL) |
| SCL Value | 1 |
Create the Transport Rule via PowerShell
Create and verify the SCL override rule targeting messages with the Resent-From header from your source domain.
Connect-ExchangeOnline New-TransportRule ` -Name "Allow Forwarded Mail" ` -HeaderMatchesMessageHeader "Resent-From" ` -HeaderMatchesPatterns "@sourcedomain\.com" ` -SetSCL 1 # Verify the rule Get-TransportRule "Allow Forwarded Mail" | Format-List Name,State,Mode
⚠️ Scope This Rule Carefully
Replace @sourcedomain.com with your actual source tenant domain. Keep the rule as narrow as possible to avoid bypassing spam filtering for unintended senders.
💡 Best Practices & Recommendations
- Use Exchange Online Partner Connectors for all trusted third-party email gateways
- Scope transport rules as narrowly as possible using specific headers or relay sources
- Remove temporary coexistence configurations after migration completion
- Consider gateways that support SRS (Sender Rewriting Scheme) and ARC to preserve email authentication during forwarding
✅ Outcome
After implementing a trusted inbound Partner Connector and a targeted transport rule for forwarded messages:
- Forwarded emails were no longer rejected with 550 5.7.68 TenantInboundAttribution
- Legitimate forwarded messages were no longer quarantined due to SPF, DKIM, or DMARC failures
- Mail flow remained fully operational throughout the coexistence and migration period while maintaining Exchange Online security controls
📚 References & Further Reading
- 🔗 Use connectors to configure mail flow in Exchange Online — Microsoft Learn
- 🔗 Mail flow rules (transport rules) in Exchange Online — Microsoft Learn
- 🔗 Email authentication in Microsoft 365 — Microsoft Learn
- 🔗 Introducing more control over Direct Send in Exchange Online — Microsoft Tech Community