Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders

Published May 19 2017 09:40 AM 26.7K Views

Update 7/10/17: Added a line about OU consideration to Important Notes section.

Until now, our on-premises customers who use  Mail Enabled Public Folders (MEPF) could not use services like Directory Based Edge Blocking (DBEB). If DBEB is enabled, any mails sent to Mail Enabled Public Folders (MEPF) will be dropped at the service network perimeter. This is because, DBEB queries Azure Active Directory (AAD) to find out if a given mail address is valid or not. Because Mail Enabled Public Folders (MEPF) are not synced to Azure Active Directory, all MEPF address are considered as invalid by DBEB. Sender of the mail to MEPF would receive following NDR:
'550 5.4.1 [<sampleMEPF>@<recipient_domain>]: Recipient address rejected: Access denied'.
To resolve this issue, in the latest Azure AD Connect tool update, we are introducing an option to synchronize MEPFs from on-premises AD to AAD. Admins can do this through the newly introduced option - 'Exchange Mail Public Folders' in Optional Features page of Custom installation during Azure AD Connect tool installation/upgrade. When you select this option, and performs a full sync, all the Mail Enabled Public Folders from on-prem AD(s) will be synced to AAD. Once synced, you can enable DBEB. Mail Enabled Public Folders addresses will no longer considered invalid addresses by DBEB. And messages will be delivered to them like they are delivered to any other recipient.

Details of version of AAD Connect tool required

This feature is available in 1.1.524.0 (May 2017) version or any later versions of Azure AD Connect tool. Azure AD Connect tool can be downloaded from following location: Download Azure AD Connect. For more details, here is the link for version history of Azure AD Connect


  • Directory Based Edge Blocking is not yet supported for Mail Enabled Public Folders hosted in Exchange Online. Current feature enables DBEB support only for Mail Enabled Public Folders hosted On-premises.
  • For Exchange Online Protection (EOP) Standalone i.e., customers who have only Exchange on-premises configured but no presence in Exchange Online, and no “advanced” features of EOP, this synchronization through AAD Connect tool is enough for DBEB to work.
  • For Exchange Online (ExO) & EOP i.e., customers who have both on-premises Exchange & Exchange Online configured, or who are using features such as DLP or ATP, this feature does not create the actual public folder objects in the Exchange Online directory. Additional synchronization via PowerShell is required for DBEB to work if you are using Exchange Online.
  • For customers who are planning to migrate Public Folders from on-premises to Exchange Online: nothing in the migration procedure has changed with this feature support. One extra point you should take care of before starting Public Folder migration to EXO is – ensure ‘Exchange Mail Public Folder’ option in Azure AD Connect tool is *not* checked. If it is checked, uncheck it before you start migration. By default, it will be unchecked.
  • In order to perform Mail Enabled Public Folders sync, along with checking 'Exchange Mail Public Folders' feature in optional features page, we need to ensure ‘Microsoft Exchange System Object’ OU of every forest from which we want to perform Mail Enabled Public Folders sync should be checked. This is present in ‘Domain and OU filtering’ page. By default, this option will be checked. NOTE: If OU was unchecked previously & it is being checked again, then full-sync has to be performed. Whenever there is any change of OU options, we need to do a full-sync for the changes to get reflected.

Customers who had a work-around in place

There were some customers who did not want to disable DBEB despite having Mail Enabled Public Folders. These customers have opted for a work-around of creating MSOL objects (like EOPMailUser, MailUser or MailContact) in Azure Active Directory with same SMTP addresses as Mail Enabled Public Folders so that these addresses are considered as valid addresses by DBEB. Customers who opted for this work-around are requested to remove all such MSOL objects before performing the sync of Mail Enabled Public Folders through AAD Connect tool. If the ‘impersonation objects’ have not been removed prior to the new synchronization, they are likely to cause a soft-match error. In soft-match error case, sync of Mail Enabled Public Folder from on-prem AD to Azure Active Directory will not succeed, and an email similar to the following will be received:
"Identity synchronization Error Report: <Date>" Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses,;Mail;]. Correct or remove the duplicate values in your local directory. Please refer to for more information on identifying objects with duplicate attribute values.
As mentioned in the description, you can correct or remove the entries with duplicate SMTP address. Below are corresponding links for each scenario: Once the objects have been cleaned up, performing a full sync will ensure Mail Enabled Public Folders are successfully synced to Azure Active Directory. More info here: Public Folder Team
Not applicable
Great move Exchange team!

Many of my customers have used the scripts here ( on the advice of TechNet to configure legacy public folder coexistence.

I find it odd that this article doesn't mention the scripts at all, and suggest this is considered a 'workaround' rather than something that should have been done.

Not applicable
Do you sync all proxy addresses to DBEB or only the Primary SMTP one?
Not applicable
All proxy addresses will be synced.
Not applicable
I still have a problem with MEPF 's (On-Premise Exchange 2010 only) and EOP.

If a MEPF is member of a E-Mail activated security group and a mail is sent to this group, the mail won't get delivered to this MEPF.

Only the other members like mailboxes or other E-Mail activated groups receive the mail.

No NDR is sent to the sender.

Within Exchange Admin Center the MEPF isn't displayed as member.

If i sent an E-mail directly to the MEPF E-Mail address it will be delivered to the MEPF.....

Is this a supported scenario?

Any ideas what could be the reason why the mail is not sent to the MEPF?

Not applicable
This is not a scenario that is in the scope of currently introduced MEPF feature in AAD Connect tool. You can raise a ticket to initiate further investigation on the issue.
Not applicable
I have the same issue (which I think is the same as Aleh describes below).

I have an hybrid Exchange setup with on-prem Distribution List, with 35 users and 1 MEPF. For on-prem users this works fine. For users with mailboxes in Office 365, when they email the DL, the email is received by all 35 people but never to the MEPF. The sender never gets an NDR either.

I have the latest version of AAD Connect, I ticked the box to enable sync'ing Exchange Mail Public Folders, and confirmed I have Microsoft Exchange System Objects ticked in 'Domain/OU Filtering' section. After running a sync, I can see in Synchronization Service Manager that all my MEPF's have sync'd sucessfully (no apparent errors).

However, when I try to send an email from an O365 mailbox user to the DL, it doesn't arrive - no NDR also.

Is there somewhere in O365 Admin Centre to view the MEPF's? There is a tab for Users (Active Users, Contacts, Guests) and Groups (Groups and Shared Mailboxes) but nowhere to see smtp addresses for MEPF's.

If I expand the DL in Admin Center, I don't see the MEPF either.

Emailing the MEPF smtp address directly from an O365 mailbox works fine.

Not applicable
All proxy addresses of a Mail Enabled Public Folder will be synced.
Not applicable
Thanks Team :) Just enabled DBEB in my Hybrid Environment this morning to get rid of the "Local Loop Detected" issue for the Invalid Recipients. Thank God I dont have MEPF. Nice article.
Not applicable
When will Mail Enabled Public Folders hosted in Exchange Online have the same protection without creating MailContacts? Seems this should have been a priority
Not applicable

Work for enabling protection of Mail Enabled Public Folders in Exchange online is in progress.

Not applicable
we implemented this feature in our environment and have some warnings on DeltaImport profile. It looks like it related to on-premise mail public folders that are members of on-premise distribution groups.

Every Delta import prompts the following warning messages in the Synchronization Service manager console:

'completed-warnings '- exported-change-not-reimported

Not applicable

We will investigate this scenario. Few questions:

1) Currently, when a mail is sent to on-premise distribution groups, is it being delivered to mail Public Folders (which is part of the distribution group)?

2) You are getting "completed-warnings - exported-change-not-reimported" only for mail Public Folders which are part of distribution groups & not for other mail Public Folders. Am I right?

We may need more info during the investigation. If you are interested, you can reach out to us at the following alias for further communication You can send the entire error message so that we will know the exact nature of the issue.

Not applicable

1) Currently, when a mail is sent to on-premise distribution groups, is it being delivered to mail Public Folders (which is part of the distribution group)?

- if you as sender located onpremise - yes. if mail send from o365 - No, because on o365 side DG does not contain PF as member (membership is not completely synconized).

2) You are getting “completed-warnings – exported-change-not-reimported” only for mail Public Folders which are part of distribution groups & not for other mail Public Folders. Am I right?

Not sure, for we remove this feature from production, but it possibly yes.

To sync mailPF to o365 we use now Sync-MailPublicFolders.ps1 as partial solution (sync mail addresses, not membership).

Not applicable
Thanks for the replies Alah
Not applicable
You will see ‘exported-change-not-reimported’ error when you have any Mail Enabled Public Folders (MEPF) as part of Distribution Lists (DL). The error is seen for each MEPF which is part of any Distribution List (DL). Impact of the error is as follows:

• As you might have already known, after we added support for syncing MEPFs to AAD, customers can enable DBEB for their organization & still receive external emails to MEPFs. Earlier, they cannot (more details can be found in this blog). Because of above bug, if a DL contains one or more MEPFs & a mail was sent to that DL from an external source, it will be received by all the recipients of the DL *except* by the MEPFs the DL contains. Note – Mails that are explicitly sent to MEPFs are delivered without any issue.

• Second impact is related to background load. As you know Azure Active Directory Connect tool does full synchronization for the first time & after that it only performs delta synchronization. Because of below error, DLs with MEPFs will be fully synchronized for every sync cycle. So, if you have large DLs with say few thousands of recipients (not just MEPFs, but all kinds of recipients included), the DL gets fully synced for every sync cycle creating load on the tool & increasing the durations for each sync.

Our suggestion is – if you don’t have any large DLs (with few thousands of recipients) which contains MEPFs, then you can ignore below error. Although, you need to take care of mails not getting delivered to MEPFs if they are sent to their parent DLs from external user. If you have large DLs that happen to have MEPF as part of them, then our suggestion would be to disable the “Exchange Mail Public Folders” option in optional features. This would remove the error from each sync cycle. But you will lose DBEB support for MEPF i.e., mails sent to MEPF won’t be received as long as DBEB is enabled.

Not applicable
FYI for others - the error we are getting here ‘exported-change-not-reimported’ is a benign error. So, there is nothing that is blocking from any data of DistributionList to be synced to AAD nor there is any issue in overall sync.
Not applicable
Any word on if something like this could be enabled for on-prem Dynamic Distribution Groups?
Not applicable

Pls, post the question in any of the AAD Connect tool forums. This blog is scoped only for the questions related to 'Exchange Mail Public Folders' option in AAD Connect tool.

Occasional Visitor

We don't have Exchange on premises, only Exchange Online, should we configure MEPF anyways in AD Connect or this doesn't apply to our environment?  Also, is DBEB something we need to consider to configure?

Senior Member

We just ran into an issue where emails to our mail enabled public folders in Exchange Online were failing, but only from our on premises relay.  The error returned by EXO was "550 5.4.1 Access Denied"  After working with MS Support, they directed me to this article where it seems that DBEB isn't supported for mail enabled public folders in EXO and hence, all accepted domains (including the ones) need to be flipped to "internalrelay".  We had already flipped our primary domain, but not the onmicrosoft ones.  I was surprised to learn about this, especially since it had been working perfectly for years but all of a sudden on 1/6 this mail flow stopped working for us.  Since this article is now 3.5 years old, and still linked by this seemgingly relevant and up to date KB article: I am wondering if there is any update to how DBEB performs in regards to mail enabled public folders hosted by EXO?

New Contributor

Hi Team!

Why should I be unchecked the "Exchange Mail Public Folder" option in Azure AD Connect tool before starting Public Folder migration to EXO? What is the problem if that option is enabled?



Occasional Visitor

Hi @The_Exchange_Team

i'm sorry but i still don't understand one thing...

I'll explain a scenario:

hybrid environment, public folder migrated from Exchange 2013 to EXO, mx pointing to EXO, SMTP domain configured as authoritative!

In this scenario, why are emails sent from outside to MEPF rejected on 550 5.4.1?

Setting the smtp domain as an internal relay MEPF begin to receive from outside as well...


I don't understand the explanation....

Exchange on premise no longer has anything to do with the flow...

MEPF now exist on EXO...

Why does the DBEB become operational? Dbeb not aware of PF on EXO?

Help me understand!!!

Version history
Last update:
‎Jul 01 2019 04:30 PM
Updated by: