Directory-Based Edge Blocking causing 550 5.4.1 NDR

Issue Overview

A customer faced a problem where all new users created in the past week and newly added proxy addresses failed to receive emails from external senders due to Directory-Based Edge Blocking causing 550 5.4.1 NDR. Internal emails worked fine, but external messages were rejected with the error:

550 5.4.1 [user@Customerdomain.com]: Recipient address rejected: Access denied.

Additionally, these rejected messages did not appear in the message traces.

---

Key Details

1. Email Setup:
   • MX records pointed to EOP (Exchange Online Protection).
   • Domains were set to Authoritative.
   • All mailboxes were hosted in the cloud.
   • The environment was configured as a Classic Full Hybrid.
   • Users were synced from on-premises Active Directory.
2. Troubleshooting Efforts:
   • MX records, send/receive connectors, and other configurations were verified as correct.
   • Despite this, the issue persisted.

---

Identifying the Cause: DBEB (Directory-Based Edge Blocking)

The problem likely stemmed from DBEB. By default, DBEB is enabled when a domain is set to Authoritative. This feature blocks messages sent to invalid recipients at the EOP layer.

How DBEB Works:

• Valid email addresses in Microsoft 365 are processed further for spam filtering and mail flow rules.
• Messages sent to invalid addresses are blocked outright, returning an error like 550 5.4.1.

For DBEB to function correctly, new users and proxy addresses must sync from on-premises to Azure AD and then propagate to EOP.

---

Actions Taken

1. Initial Attempt:
   A new value was added to a problematic user to trigger a sync with EOP. However, this did not resolve the issue.
2. Workaround:
   The domain setting was temporarily changed to Internal Relay in the portal, disabling DBEB. This resolved the issue, allowing external emails to be delivered successfully.
3. Testing the Change:
   • Re-enabling DBEB by setting the domain back to Authoritative brought the problem back.
   • Adding a new proxy address to the user triggered the same issue under the Authoritative setting.
4. Current State:
   The domain remains set to Internal Relay as a workaround, awaiting a permanent fix from Microsoft.

---

Microsoft Support Findings

Microsoft Premier Support confirmed the root cause: a backend sync failure within Office 365, affecting other customers as well. Relevant Service Incident IDs include EX293644 and EX293978.

---

Recommendations

• Use Internal Relay temporarily to bypass DBEB if you encounter this issue.
• Once Microsoft resolves the backend sync issue, revert the domain setting to Authoritative to benefit from DBEB’s features.
• Monitor updates from Microsoft for a permanent fix.

Note: While Internal Relay is a viable short-term solution, it may cause issues with misconfigured send connectors. Ensure proper configurations before implementing this workaround.

---

Let me know if you need further adjustments or additional insights!