Directory-Based Edge Blocking causing 550 5.4.1 NDR

Recently working with a customer on this case – want to share findings.

Customer was facing issue where all new users created since app a week, and also all newly added proxy addresses would fail to receive mails coming from external senders. So they could send internal mails to these recipients fine, but anything coming from internet failed with:

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

Another strange thing was, there was no trace of these rejected messages in the Message traces…. – Worth noting here the following facts:

  • MX records are pointing towards EOP
  • All domains are set to Authoritative
  • All mailboxes are in the cloud
  • Hybrid is Classic Full
  • Users are synced from Onprem

Customer had already done alot of troubleshooting, so MX records, send/ receive connectors etc was all good.

After confirming all this it led me to think of DBEB causing this, because although as a customer you would tend to think of Exchange Online as a “whole” it actually consist of many moving parts, among others EOP (Exchange Online Protection) and Exchange online itself, and today the default is that when setting a domain to Authoritative DBEB is automatically enabled.

So what is DBEB – Source: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-directory-based-edge-blocking

Directory-Based Edge Blocking (DBEB) lets you reject messages for invalid recipients at the service network perimeter in Microsoft 365 organizations with Exchange Online mailboxes and in standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes. DBEB lets admins add mail-enabled recipients to Microsoft 365 or Office 365 and block all messages sent to email addresses that aren’t present in Microsoft 365 or Office 365.

If a message is sent to a valid email address in Microsoft 365 or Office 365, the message continues through the rest of the service filtering layers: anti-malware, anti-spam, and mail flow rules (also known as transport rules). If the address doesn’t exist, the service blocks the message before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this: 550 5.4.1 Recipient address rejected: Access denied.

Aha, so basically this would require new users or added proxy addresses to have been synced not only from onprem til AAD, but also further along to EOP, in order for this to work.

Then we tried adding a new value to one of the problematic users and triggering sync – theory being all values would the refresh in EOP – no difference.

Customer was running a ticket through Premier support for this also, and after explaining the issue to them, we decided to go ahead and change the domain to “Internal Relay” in the portal.

And thereby in effect disabling DBEB – and this did help – now mails were deliverede succesfully to the recipients.

Then we tried:

  • Reenabling DBEB by setting back to Authoritative – Problem came back
  • Adding NEW value to problematic user, now same issue, but only for added proxy (with domain as authoritative)

So we decided to go back to Internal Relay and stay there for the time being as a workaround.

Then the next day – Microsoft Premier support came back to us confirming our suspicion, this is caused by failing backend sync internally in O365, and actually affected other customers as well. So Headsup, if you see this issue go to “Internal Relay” to disable DBEB.

You should be able to find the SI in your Admin Centre by ref: EX293644 or EX293978

THAT being said, this is not a permanent solution, DBEB has many benefits, and actually Internal Relay can cause many problems with badly configured Send Connectors, so as soon as MS confirms a fix, we go back to “Authoritative”

Thanks for taking your time.

Leave a Reply

Your email address will not be published. Required fields are marked *