Directory Based Edge Blocking for Exchange Online Protection

We have received consistent feedback from our customers that the ability to reject messages for invalid recipients at the service network perimeter is important. We are aggressively working to design a solution that will make Directory Based Edge Blocking (DBEB) available within Exchange Online Protection (EOP).  This functionality is targeted to be added to the service in the first quarter of 2014.

In the meantime, here are some suggested configurations to help customers who want this type of capability until the service is able to offer recipient validation:  

  • Enabling Recipient filteringon-premises on your Exchange servers.  This is the recommended solution until the EOP functionality is available. This essentially adds one step to the process of communications.  EOP will communicate with your Exchange servers and then Exchange recipient filtering can handle as configured:  
    • Customer Concern:  Increased load on on-premises servers?
    • Microsoft response:  Impact to the customer’s servers should be minimal. The Recipient Validation feature will reject recipients after the RCPT TO:  command within the SMTP conversation well before accepting the message into the org.  Because of this the resources expended are very minimal and the cost of NDR generation is on the EOP side which will result in minimal impact to your on-premises servers.
  • Transport rules can be used to mimic the behavior as well, and would have to be tested to each customers’ desired configuration.

Wendy Wilkes
Senior Program Manager
Office 365 Customer Experience

Updated 11/21/2013 to include the target release timeframe.

Comments (14)
  1. Kevin says:

    Your suggestions assume that Exchange is the internal edge within the organization. That is not our architecture. Even if it were, we had assumed that the edge services we are purchasing from Microsoft would have functionality common to all edge service offerings. Next thing you'll be telling us the end user quarantine is gone. Oh, wait.

    Perhaps you could consider spinning off the former FOPE as a separate company, maybe call it FrontBridge, so that your customers will have an alternative that offers a full set of edge service functionality.

  2. Matt says:

    Well this is unnerving.  Why isn't the fact that this feature is missing from EOP stated anywhere on the communications I've received from Microsoft about the transition?   Those emails, and the website they direct me to, make no mention about losing any features that are currently present in FOPE.   In fact, the email I received says "As part of the transition we will move all of your policy settings and configuration to the new service".    Apparently "all" doesn't mean what I thought it meant.   Recipient validation I would think is part of "all" the policies we have set up today.   And another commentor, Kevin, strongly implies EUQ being gone too, is that true?  If so, that will be a huge problem for us.   I have to plan to retrain 10,000 users if that's the case, as well as find another product to re-implement that functionality.

    What else haven't you told us?   What else is missing from EOP that we are using today in FOPE?  I *NEED* to know this to plan effectively.    "Leave the work to us" suddenly sounds like a good way to be in front of management the day after the transition explaining why things aren't working the way they did previously.

    My confidence is a bit shaken, to say the least.  Maybe it's time to shop for another service that has better communication with their customers.   Or that doesn't put you through an "upgrade" that removes features you are already paying for, and rely upon.

  3. Devin L. Ganger says:

    You already *have* a mechanism in-place with Exchange that will work whether Exchange is the internal edge or not — EdgeSync subscriptions. Implement them from the EOP side. BOOM.

  4. Wendy_MSFT says:

    FOPE Standalone customers who are currently using DBEB in FOPE will not be migrated to Office 365 until this feature has been added to EOP. We have a feature comparison table available that compares FOPE to EOP.…/dn305011(v=exchg.150).aspx

  5. John says:

    My On-Premises Barracuda works 100% better than EOP.

    We do not trust Public Cloud services after NSA PRISM revelations.

  6. msemack says:

    Can you post an example of how to setup a Transport Rule to mimic the Directory Based blocking in EOP?  Using Transport Rules, I can manually enter a list of addresses to allow/block, but I see no way to auto-update the rule based on Directory Sync.  Do I just have to maintain a manual whitelist?

  7. Wendy_MSFT says:

    We do not recommend the transport rule for exactly the reason you called out. You would need to either add all proxy addresses to the rule, or use a group which much be maintained in order to keep the recipient list current. Recipient filtering is easier to maintain because there is no risk that a new mailbox would have not been added to the correct DG and inadvertently have their mail rejected.

  8. Wendy_MSFT says:

    Also, if you have a mixture of online and on-premises mailboxes you can sync your user list to Office365 and configure your domains as 'Authoritative'. This will enable the recipient filtering within the service. Whether the intended recipient has a mailbox on premises or in Exchange Online, the service will manage the rejections for invalid recipients.

  9. Christiaan says:

    Also very concerned about DBEB not yet ready for prime time.  Glad to hear Wendy_MSFT point out we won't be moved until it's ready (and tested and stabilised?).

    Sounds like a small gripe, but loosing scheduled reports will be a nuisance – having to manually log-in. 'No, we recommend that you run interactive reports in the Office 365 admin center instead.' (from vs page). All I want(ed) was a weekly volumes report e-mailed to me.

  10. Benney says:

    We are a customer using FOPE (with DBEB) in our Exchange hybrid configuration. We received our Office 365 upgrade weeks ago but the FOPE to EOP migration is still not done. Is the fact that we had DBEB enabled putting our EOP upgrade on hold until they implement DBEB?

  11. Wendy_MSFT says:

    Hi Benney – The upgrades for customers already in Exchange Online are not being held back for DBEB.

  12. Don says:

    Wendy, your comment:  "FOPE Standalone customers who are currently using DBEB in FOPE will not be migrated to Office 365 until this feature has been added to EOP" still leaves me with questions.

    Our company is a combination of FOPE Standalone 'and' Office 365 cloud users.  Our Standalone covers 2 on-premise domains and part of a shared domain with the O365 cloud.  We have zero Exchange servers on premise and rely on the FOPE DBEB for all inbound mail whether it is bound for the cloud or our stand alone users.

    I have received the notice from MS that we will be migrated within 4 weeks, but you said above that we will not be migrated.  What is the answer?

    P.S. I VERY MUCH agree with the posts by Kevin and Matt.  I am angered that we researched and selected O365 and FOPE, which had to be uniquely customized to fit our odd configuration, just to have it replaced with a product that doesn't have the same required features–and NOT BE TOLD ABOUT IT.  Everything I have heard about the upgrade, I have had to dig in a research myself.  I was initially under the understanding that everything would be migrated to the new EOP/O365 wave 15, but in reality this is a LIE!

  13. Wendy_MSFT says:

    Hi Don – if you have an environment which is shared across Exchange Online and an on-premises mailbox infrastructure you will still have the ability to have the recipient rejection performed within the service even after the upgrade to wave15. This is why DBEB is not an upgrade blocker for customers unless they are FOPE Standalone (no Exchange Online integration at all). As I mentioned earlier, when an Exchange Online customer has added all of their valid recipients to the Office 365 Active Directory you can change your domain type to "Authoritative" in the service. "Authoritative" means that all known recipients are discoverable, and if the recipient doesn't exist then the messages are rejected. It does not matter whether initial delivery of your mail is destined for an on-premises environment or routed through the cloud initially. If the recipient is in the directory, the mail will be accepted. Customers today who have no Exchange Online integration (who are being upgraded to EOP Standalone) do not have the ability to configure their domain type in Office 365. Without that ability today, they cannot perform recipient validation within the service. You can, however. I really hope that helps.

  14. Kingson says:

    Transport rules can be used to mimic the behavior as well, and would have to be tested to each customers' desired configuration.

    If you people prefer to reject messages for non-existent user, Create a Distribution Group and add all users as a members.

    1. DL Contains all members.

    2. If the sender is Located "Outside the Organization"

    3. Block the Message.. " Reject with Explanation"

    4. Except if the Recipient is member of . Distribution Group (Contains all users as members)

    DomainType needs to set it as InternalRelay, Do not try this in co-existence scenario.

    Changing the action to Redirect to other mailbox, Will make the above Transport rules to work in Catch all mailbox concept.



Comments are closed.