In Deployment: Directory Based Edge Blocking for Exchange Online Protection

What is Directory Based Edge Blocking?

The Directory Based Edge Blocking (DBEB) feature in Exchange Online Protection (EOP) lets you reject messages for invalid recipients at the service network perimeter. DBEB lets admins add mail-enabled recipients to Azure Active Directory and block all messages sent to email addresses that aren’t present in Azure Active Directory.

If a message is sent to a valid email address present in Azure Active Directory, the message continues through the rest of the service filtering layers (anti-malware, anti-spam, transport rules). If the address is not present, the service blocks the message before filtering occurs, and a non-delivery report (NDR) is sent to the sender informing them that their message was not delivered.

How is DBEB enabled?

Admins can manage the DBEB feature through configuration of the domain type in the Exchange admin center (EAC). The EAC exposes two domain types:

  • Authoritative - Email is delivered to valid recipients in your organization which may include local recipients as well as recipients whose messages are being routed to a shared environment. All email for unknown recipients is rejected. Setting this domain type is what enables DBEB.
  • Internal relay - Email is delivered to recipients in your organization or relayed to an email server at another physical or logical location.

What does this mean for you?

There are three ways for you to purchase Exchange Online Protection (EOP). In most ways they are the same, but there are some differences. How new features are deployed is one of the differences.

EOP Standalone

You now have the ability to change your domain type in the EAC. Once the feature has been fully deployed the messages for invalid recipients will start being rejected for domains that have been configured as Authoritative.

The default domain type for a new domain in EOP Standalone is Internal relay. This domain type allows your email messages to route through EOP and have all the rules and filtering applied to them for all recipients for each of your domains.

In order to enable DBEB you need to change your domain type to Authoritative after configuring directory synchronization and ensuring that all of your mail enabled objects are present. This changes the behavior of the service so that it rejects all messages at the network perimeter to any recipient for your domain that is not present in Windows Azure Active Directory. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

EOP as part of the Exchange Enterprise CAL with Services and with Exchange Online

You have always had the ability to change your domain type in the EAC. This means that you may already have synchronized your users and configured your domains as Authoritative in order for recipient blocking to occur within EOP. The difference for you is more subtle.

Currently, messages for invalid recipients enter the filtering network and are being rejected during the same process which processes your Transport Rules. With the introduction of DBEB, messages will now be blocked ahead of the Transport Rules in the messaging pipeline.

You’ll know that the deployment is complete for your organization when you see an increase in your SMTP blocked message count in the received spam report. A reporting update is coming soon that will separate the DBEB specific blocks from the other SMTP blocks, so if you have the updated report before DBEB finished deployment, you’ll see the message count in the DBEB section of the received spam report.

Information for Upgraded FOPE Customers

In FOPE Directory Based Edge Blocking (DBEB) allows you to upload a list of legitimate SMTP addresses to the service and take action based on those addresses. The only action that’s being introduced for DBEB in EOP is the equivalent of “Reject”.

We’ll migrate all enabled users that are present in the FOPE Administration Center to Office 365 as part of your transition from FOPE to EOP. This will ensure that your current list of FOPE users is present in the Windows Azure Active Directory when you’re upgraded. We strongly recommend that if you have any clean-up to do for the users currently in FOPE, you should do so prior to your upgrade. We also recommend that you configure directory synchronization with Office 365 before updating your MX record to point to EOP. The directory synchronization has built in logic to match up any existing user objects in Office 365 with their on-premises directory objects, based on properties like SMTP proxy address. For more information about how to set up directory synchronization, see "Use directory synchronization to manage recipients" in Manage Recipients in EOP.

For each domain within your organization, the User List Source and Directory-Based Edge Blocking mode will determine the domain type used for your upgrade. If your User List Source in FOPE is configured to use Admin Center or Directory Synchronization Tool and your DBEB mode is set to Reject, your domain will be added to EOP and configured as Authoritative. All other User List Source + DBEB mode combinations will be added as Internal relay, so if you want to enable DBEB you’ll need to change this to Authoritative after your transition is complete.

What about everything else?

  • User List Source = Secure FTP: SFTP is not supported in EOP, however we are adding the ability to manage users and groups via PowerShell and will provide guidance for updating them using PowerShell. We understand that this is a change, but we believe it will be significantly better in the long term. You will still be able to manage your users and groups in bulk, as well as schedule and automate the import, so we are hopeful this will fill the same feature niche which SFTP was filling in FOPE. In EOP there are no Virtual Domains as the functionality has been replaced by being able to define specific Transport Rules, Spam Policy and Criteria Based Routing based on Groups. If your current User List Source is Secure FTP, you will not be migrated until the ability to use PowerShell for loading the recipients, and the associated guidance, has been provided. This should be coming soon. After your upgrade is finalized you will need to add your users to Office 365 and update your domain type to Authoritative.
  • User List Source = Legacy Directory Synchronization Tool: The Legacy Directory Synchronization Tool is not supported in EOP. In order to maintain DBEB for your domain you will need to configure directory synchronization with Office 365 and update your domain type to Authoritative.
  • Directory-Based Edge Blocking mode = Reject-Test: Reject-Test will be migrated as Internal Relay. Reject-Test in FOPE allows all mail for valid recipients to pass through the service, and will redirect messages for invalid recipients to a specific mailbox. This is useful in scenarios where you’re not 100% confident that your entire user list is populated in the service. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
  • Directory-Based Edge Blocking mode = Pass-Through: Pass-Through will be migrated as Internal Relay. Pass-Through in FOPE allows filtering to be applied only for a sub-set of recipients who are provisioned in the service, and bypass filtering for all other recipients. This is useful in scenarios where you’re routing mail through the service and want to see what the filtering impact is for a subset of your domain recipients. This condition is meant to be temporary only. Transport Rules in EOP can be used to mimic the behavior and would have to be tested to each customer’s desired configuration.
  • Directory-Based Edge Blocking mode = Passive (Virtual Domain Creation Only): Passive will be migrated as Internal relay. Passive mode in FOPE allows you to configure Virtual Domains for that domain without needing to provide a user list for the Parent Domain. In EOP there are no Virtual Domains, as the functionality has been replaced by the ability to define specific Transport Rules, Spam Policy, and Criteria Based Routing based on Groups.

Wendy Wilkes
Senior Program Manager
Office 365 Customer Experience

Comments (44)
  1. Wendy_MSFT says:

    Hello Everyone: DBEB is now live and available for EOP Standalone customers! Woo-hoo! :)

  2. Wendy_MSFT says:

    Hi Brian Brinkers – It is not just you. The feature is in deployment and will be enabled for all EOP Standalone domains over the next couple of days. The first step is the ability to configure the domain as Authoritative. The second step is to enable the
    feature. I expect this to happen within the next couple of days and will post a comment here to let you know when that has been done.

  3. Wendy_MSFT says:

    Hi msemack.rtd – the technology behind the DBEB feature can allow some invalid addresses through, but these should be very rare. If you are seeing a large number of invalid recipients getting through please open up a Support incident so that we can investigate whether there is something being incorrectly applied by the service.

  4. Wendy_MSFT says:

    Hi Vasil – No, the sender and recipient information for messages which are blocked at the network perimeter do not show up in the message trace results. They will show up as message count only in the spam report.

  5. Wendy_MSFT says:

    Hi Mike R – If you are in Hybrid mode then you are part of the Exchange Online deployment. You should be able to have your messages rejected within the service for invalid recipients already if your domain is configured as “Authoritative”. There is one caveat, though, as EOP requires that your upgrade to the new service is complete. If you are still routing mail through FOPE then the EOP DBEB feature instructions do not apply. I only bring that up because you state that the bounce is not being generated by Forefront. In the current version of the Office 365 Exchange Online service the EOP layer is completely integrated within the message transport pipeline, and there is no more routing through FOPE at all.

  6. agrajag42 says:

    Hey Wendy! We are currently on Wave 15 with FOPE, EOP (as a passthrough mostly) and we have Dirsync running. We use the Secure FTP to upload the list of internet routable email addresses to FOPE. All of our mailboxes are on Office 365 with the exception
    of a few on premise Exchange mailboxes and a ton of Unix mailhosts and lists. I have a three questions. How do you restrict mail enabled objects in the directory that you don’t want to receive email from the internet, but that you want to be open for internal
    use. For example, I have an site email list that I can’t restrict because a Unix mailhost might email it. That Unix mailhost is not in my directory. I also don’t want this list to receive email from the internet. On the flip side, I have some Unix mailhosts
    that I want to receive email from the internet. Do they need to have mail enabled users (or Contacts) in Active Directory or can they be added using the User Source List? Lastly, does DBEB and Authoratative prevent you from emailing anything that might reside
    on-premise that is not in Windows Azure Active Directory or will it still forward unresolved addresses in to our Unix smarthost? Thanks!

  7. Wendy_MSFT says:

    Hi Carsten_66 – It sounds like you are talking about FOPE, and not EOP. If you choose the User List Source to Exchange Online it does not result in the objects from Office 365 being synchronized back to FOPE, and it will actually result in DBEB being disabled for your domain. In order to have FOPE take action on those Office 365 objects you will need to add them to FOPE. Once your upgrade to EOP is completed, however, objects from your on-premises and sourced from Exchange Online will all be applied to DBEB.

  8. Wendy_MSFT says:

    Hi Bill – If you’ve set your domains to Authoritative just check back in a couple of days. As I mentioned above, we will be turning it on across the Standalone customers shortly. You don’t have to do anything else.

  9. Wendy_MSFT says:

    Hi Mike R – There could be other factors which are contributing to not getting the recipient filtering in the service layer. If you would not mind opening up a Support incident then posting your Support Ticket number, I would like to take a look and see if we can get this working for you.

  10. Anonymous says:

    Sorry to resurrect an old topic, but I have noticed that DBEB is not being applied consistently since its rollout. If I sent test messages to bogus address in our organization, some addresses get blocked by EOP but others are allowed through. I have checked to make sure the uses that come through were not somehow listed on our synced Active Directory. Is there something I am missing?

  11. Wendy_MSFT says:

    Hi agrajag42: In EOP you can create Transport Rules to only allow delivery to those directory objects when the source is you Unix mail host, especially if they send from a static list of IPs. You can also use “is external/internal” to restrict delivery. Setting the domain as Authoritative will prevent mail from being relayed to your on-premises servers for any object not present in Windows Azure Active Directory. If you want to forward unresolved addresses to your Unix smart host then you would need to configure the domain as Internal Relay. We cannot both reject messages for all unknown recipients and forward unresolved addresses for the domain.

  12. Wendy_MSFT says:

    Hi MSEMACK – If you’ve set your domains to Authoritative just check back in a couple of days. We will be turning it on across the Standalone customers shortly. You don’t have to do anything else.

  13. Vasil says:

    So we will be able to see those in the tracking reports as well?

  14. bill says:

    Public Cloud marketing junk “There are three ways for you to purchase Exchange Online Protection (EOP).”
    When are we getting Exchange Server 2013 Edge role for Exchange 2013 ON-PREMISES?
    Exchange Server 2013 SP1?

  15. msemack says:

    EOP Standalone customer here. I am trying to enable DBEB and it is not working for me.

    I set our domains to Authoritative in our EOP instance under mail flow -> accepted domains (we are a stand-alone EOP customer). We already have Directory Sync enabled and working. It has been in place for months, and user accounts are properly listed in Office 365 / EOP.

    However, if I send an e-mail to a bogus address in our domain, the bounce message is generated by our on-premises Exchange server, NOT EOP.

    I waited an hour after switching to Authoritative. I figured that would be long enough for the change to propagate.

    Is there something else I need to do?

  16. Mike R. says:


    Same issue as msemack. Running in Hybrid mode with everything working in O365 for 6 months now. When I inspect the header information it is clear that the NDR is generated by our on site Exchange, not Forefront. This feature appears broken and or there is a lack of set up information to make this work correctly. Ran a manual DirSync with no luck. Made sure authoritative was set.

    Do you actually test the software before you release it? You should.

  17. Billnotgates says:

    Bill is the man:)
    we want sp1
    we want sp1
    we want sp1
    or else…:)
    we’ll take sp2 also if u have it:)
    sp2 wont even have ecp… it will install and manage itself

  18. JJ says:

    Can we please just bring back the damn onsite services? Edge and TMG were fantastic products and you’ve completely borked it by removing them.

  19. Joe says:

    As every Customers telling you, BRING BACK THE EDGE role for Exchange Server 2013.
    Do not care about EOP on Public Cloud.

  20. Wayne says:

    @Bill, @BillnotGates, @jj, @Joe – Edge role is on track for SP1, you will all get it very soon!

  21. Kurt Wallander says:


    I’m afraid there are two camps here. Those who want to move to the cloud and those who prefer local. I happen to fall into the latter group. When you come here and extol DBEB, you are kink of kicking sand into the faces of administrators like myself. It seems that the Exchange on premises folks are continually getting features removed and we are expected to switch some of the options to the cloud. In most cases I’m seeing solutions presented that are not as elegant and are more limiting than previous versions of Exchange. What was previously working great (i.e. An Edge server handling LDAP verifications and Threat Management Gateway handling everything else) has now been removed and a mediocre cloud-based solution has been plopped down in it’s place. I understand that Microsoft wants every one to pay them monthly fees, but by killing your on premises options, you’re just continually kicking sand in our faces. We DO NOT WANT what you are offering. We want what we already had working in place that was way more customizable and functional than what you are coming here today and offering us. We simply do not want the cloud and I find it very insulting the situation we now find ourselves in with what you have, in essence, forced us to do. Yes, we could stay on 2010, but eventually we will have to upgrade because you’ll cut off support. At that point, I’m afraid, I’m going to have to find another solution other than what Microsoft is offering. I don’t think Office 365 is a good deal, especially for companies over 200 users. In fact, I think it easily doubles the costs. Please take this feedback to your team that we really want you to bring back Edge as well as ISA/TMG and all the other on premises solutions that you had before. I don’t expect them to be amazing, I just want them to actually be available. We are not moving to the cloud no matter what, so please provide us on premises solutions that do what you are talking about above. Don’t force us into the cloud because, we will choose Google over what you are offering. Your price plans are just way too high for larger companies.

  22. Kurt Wallander says:

    Wayne, A year and a half later we finally get Edge for on premises with SP1? Speaks volumes as to what your priorities are for on premises customers. We appear to be beta testers that are getting the shaft. These aren’t new features. These are the SAME features that were available in 2010. Shameful the state of on premises.

  23. Microsoft_Listen_2_your_Customers says:

    STOP pushing Public Cloud services such as EOP.
    The Public Cloud is infested with Security issues.
    Start giving Exchange On-Premises customers what they want such as Edge.

  24. GlassHalfFull says:

    I originally read this article and agreed with the sentiments on the replies, thinking that perhaps the best solution would be to have an “Exchange Online” blog that is different than an “Exchange On-Premisis” blog, since a lot of the blog posts tend to be online-centric, or at least – respectfully – somewhat antisocial to the onpremesis crowd.

    But then I realized that the unification of the code kind of prohibits that. There really is no difference from a “online/onprem” codebase solution, so some articles tend to focus on an aspect of the code.

    So having said that, respectfully, ALL articles need to be written from BOTH customer viewpoints, otherwise I agree with the original poster who claimed that articles like these start to sound like a selling point. If the team is going to write a article detailing the features of a product in one context and ignore the other contexts, then you’re effectively pushing the sale. And to that end, while I’ve never posted here before, have to agree that this is not helping the strategy.

    I know there are good people on the team just throwing out good information as they can, but as you can tell from the replies – and I count myself amongst them – I am getting tired of hearing about features I don’t have from a so-called “unified code-base product”, and the message gets cloudy. Please stop this…

  25. Disgruntled Admin says:

    As Golum would say, “We hates it!”. We’ve tried the Office 365 and not a single one of our test users liked the interface. When are you going to update the POS interface so it doesn’t cause our employees to want to rip their eyeballs out? From an administrative side, the DirSync tool looks like some high-school student wrote it. You’ve got parts of it in the DirSync, parts of it in PowerShell, parts of it in the MSOL PowerShell, and parts of it in the EAC. Good lord, it looks like it’s been hacked together as some kind of Alpha test. I was floored when I realized this is actually the correct way to DirSync. Very poor job with the whole Office 365 offering. WFW 3.11 did a better job.

  26. ? says:

    The comments to this blog are hilarious! But seriously, Microsoft, please give on-prem guys some love will ya?

  27. adam says:

    Sure, everyone wants to give ALL their data to the Public Cloud that is infested with Security issues (NSA PRISM Backdoor Access………) :-)

  28. Ian_R says:

    I’m doing a trial with standalone EOP at them moment to see if it would be suitable for one of our clients with onsite Exchange 2010. Also can’t get it to bounce emails to unknown users. Any news when this will be working?

  29. I_Agree says:

    I agree Public Cloud is infested with Security Issues, a good option is Private Cloud & Exchange On-Premises…….

  30. Mike R. says:


    Writing again. I am in hybrid mode. My domain is authoritative. I am not routing through FOPE. I can’t get the Edge Blocking as you described above to work for love or money. I’ve tried ever since you posted this article and it just does not work. E-mails that should generate an NDR are not bouncing from the Edge. Can you please provide additional documentation or steps on how to get this bloody thing working right? As far as I can tell this does not work at all. It is broken.

  31. bill says:

    “Email is delivered to valid recipients in your organization which may include local recipients as well as recipients whose messages are being routed to a shared environment. All email for unknown recipients is rejected.”

    Is there a step by step documentation process with screenshots somewhere that makes this idiot proof? We just performed a test from an external Gmail account to our domain after configuring authoritative, however, the message then appears in our on premises Exchange 2010 tracking logs. The filtering is not working. We must be missing a step or two in the set up. Thank you.

  32. pesospesos says:

    can someone check PSS case 113122011043395 and advise if this will be fixed in SP1?

  33. Public_Cloud_Security_Issues?? says:

    Why on Earth would you say Public Cloud / Office 365 have Security Issues?? LOL
    Check this, “Vulnerability to obtain full Administrative permissions over their entire company’s Office 365 environment”

  34. Brian Brinkers says:

    Does anyone out side of the Exchange team themselves actually have this feature working? We can’t get it working either.

  35. Brain says:

    I must have missed the "In Deployment" part of the article. That explains why it isn’t working. Doh! Does anyone have a recommendation for an onsite replacement instead? I support a few customers and one of them is looking for a direct replacement for
    their installed Threat Management Gateway, but they do not want to move to the cloud at this time. Thanks peace out.

  36. On-Premises_Email_Hygiene_Appliance says:

    @Brain I had several Customers that DO NOT trust Public Cloud (security wild wild west) & wanted On-Premises Email Hygiene Appliance. Your options would be Exchange Edge, Barracuda or Cisco IronPort. I like Barracuda :-)

  37. Dollars says:

    Exchange Team: Please close PSS case 113122011043395.

  38. msemack says:

    It has been over a week, and DBEB is still not working for us. I re-confirmed that we are set for Authoritative. Is there a problem?

  39. Barracuda says:

    Barracuda has been doing this for years using an LDAP connection to an Active Directory forest with Exchange installed.

  40. Carsten_66 says:

    I am using DBEB and want to keep doing so. It works just fine, and blocking is taking place where it needs to: this environment is in hybrid and is using DirSync.

    One question: I have some objects created in O365 ONLY that cannot be addressed from outside (since its NOT synced using dirsync I assume to FOPE). I see the choice to use Exchange Online as the Source: we are Syncing with Exchange Online / o365; if I change the source from Directory Synchronization Tool to Exchange Online, will I then get objects exclusively found in o365 AND synced from on-prem AD available/used for validation in DBEB?


  41. why-owhy says:

    we are currently a FOPE customer, and have been using the dirsync tool for over 3 years, it just works, no issues, no big install, seperate server, etc. Looking at the transition docs, its telling me since i dont use a public name in the users UPN, i have to make changes that may impact all our users (alternate UPN), and use a dedicated server, with sql installed. Why has this process gone from a simple tool, to a massive pain?

  42. Myron A. Semack says:

    Sorry to resurrect an old post, but I have noticed some inconsistency in how DBEB is working. Some invalid recipients get rejected by EOP, but some do not (and get rejected by our internal mail server). I have confirmed the invalid recipients that are still making it through EOP are not listed in Active Directory. Is there something I am missing?

  43. thomas says:

    I know we can manage O365 users using PowerShell but when can we manage EOP groups and recipients using Powershell? I read to expect it in Q2 of 2014- is this confirmed?

Comments are closed.

Skip to main content