In Deployment: Directory Based Edge Blocking for Exchange Online Protection

[The_Exchange_Team]

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