Mail-Enabled Public Folders & Directory-Based Edge Blocking

Directory-Based Edge Blocking (DBEB) is a feature in Exchange Online Protection which automatically blocks email messages sent to recipients that do not exist in the Office 365 tenant. By default, DBEB is enabled for every domain in the tenant.

When a message is sent to a non-existent recipient, the sender will get the following NDR:

Remote Server returned '550 5.4.1 [email@domain.com]: Recipient address rejected: Access denied'

In a hybrid Exchange deployment, mail flow can be configured in various ways. A very common scenario is to use EOP as the primary filtering service for both on-premises and Office 365 recipients. Because you must setup directory synchronization with Office 365 as part of the hybrid deployment, EOP automatically knows about all the on-premises recipients and will accept emails for those on-premises recipients –even though they don’t necessarily have a mailbox in Office 365. This is the same when you are not in a hybrid deployment, but have setup directory synchronization and are just using EOP to protect on-premises recipients.

Unfortunately, Azure AD Connect (or any previous version of the directory synchronization tool) has a significant limitation: it does not synchronize mail-enabled public folders. As a result, newly created mail-enabled Public Folders are not automatically created as a recipient in Office 365 and mail will not be delivered until you create corresponding objects yourself. For this purpose, Microsoft has created a series of scripts which can automatically create “mail-enabled public folders” for you whenever you add a new mail-enabled public folder on-premises. You can schedule the scripts to automatically run every so often and thus create a sort of automatic synchronization. The scripts do not synchronize an object with Azure AD, instead they create a “sync mail public folder” in Exchange Online. This object is the counterpart that depicts an on-premises Public Folder. Once the object is created in Office 365, DBEB should normally pick up the new recipient and mail should start flowing. Should normally…

In reality, however, this is not the case. EOP and mail-enabled public folders (or at least the sync mail public folders) do not play well together. When you are lucky the provisioning of the sync mail public folder succeeds and emails will start flowing within the hour (this is approximately how long it takes to replicate changes across all EOP instances). If you are unlucky, EOP does not pick the new objects up and mail will still be blocked by DBEB because it doesn’t know about the new on-premises public folders.

The solution (also according to Microsoft support) is super easy: you change the domain type from Authoritative to Internal Relay in Exchange Online. Doing so will disabled DBEB and mail will be delivered to your on-premises mail-enabled public folders… Now before you go off and make that change: think a second about what this means. By disabling DBEB, you potentially open up your on-premises environment to a significant increase in traffic because email for recipients that do not exist in Exchange Online will automatically be forwarded to your on-premises Exchange server instead of being rejected. Secondly, if the recipient does not exist on-premises, the email will be sent back to Exchange Online where it will be forwarded to on-premises again, etc… So, yes, you potentially open yourself up for mail loops. Even though Exchange does have ways to detect mail loops (after the message has been sent back/forth a few times), it does not stop from hitting your on-premises serves a few times first…

In my opinion is disabling DBEB not really a great solution. Alternatively, you can (manually) create contact objects (in very much the same way contacts / MEUs exists for on-premises mailboxes) which then allow mail to pass DBEB and be delivered on-premises. This approach works great if you do not have many mail-enabled public folders. But what if you do have hundreds, maybe thousands to provision?

Regardless of the path you take, I believe this is thoroughly broken and needs to be fixed by Microsoft. According to the following blog post, Microsoft knows about this and is working on a solution. Until then, make sure to plan properly and don’t get caught by surprise!

Cheers,

Michael