With the ongoing growing number of (successful) phishing attacks entering the organization via email, there’s an increasing demand for a rock-solid message hygiene solution. In my opinion there are very little on-premises solutions that do a great job, and very little cloud solutions. Google has a great message hygiene solution, but Microsoft’s Exchange Online Protection (EOP) is getting better and better each year. Not surprisingly since both Google and Microsoft can invest a tremendous amount of R&D money in their message hygiene solution.

A lot of my on-premises customers are currently looking at Exchange Online Protection (EOP) and are thinking about implementing EOP on a short term. In this blogpost I will focus on implementing EOP when using on-premises Exchange server (2010 or higher). An existing implementation can look something like this:

There’s an Exchange mailbox server on-premises, and in the organization’s DMZ there’s a mail relay server. In my environment this is an Exchange Edge Transport server, but this can be any SMTP server of course. MX records are pointing to the Edge Transport Server in the DMZ, the Internet Send Connector is using the Edge Transport Server as the source transport server. Between the Mailbox server and the Edge Transport server there’s an Edge Synchronization running to keep the Edge Transport server up-to-date with internal information.

The MX record here is pointing to smtphost.exchange2019.nl and this is also the outbound server. The SPF record is pretty simple in this scenario since there’s only one egress point for my email, so the record is V=spf1 ip4:176.62.196.247 -all.

At this point there’s no DKIM signing or verification (not available in on-premises Exchange) and there’s also no DMARC record.

Exchange Online Protection

Exchange Online Protection is Microsoft message hygiene solution. Before EOP it was called Forefront Online Protection for Exchange (FOPE). The original version was created by FrontBridge, which was acquired by Microsoft in 2005.

You can get a separate EOP subscription, but EOP is automatically part of any Exchange Online subscription, so you must do the math to figure out the best value for money.

EOP can be used for inbound mail and for outbound mail. To implement EOP for inbound mail it’s just a matter of changing the MX records so that they point to EOP instead of your on-premises mail servers. For outbound mail you have to change the Internet Send Connector to use EOP as a smart host. All outbound email will then be forwarded to EOP and delivered to the intended recipients by EOP.

In my lab environment I have been working with Edge Transport servers since the beginning. From a message hygiene perspective, they do a great job when it comes to connection filtering, but other than that message hygiene is so-so.
The desired configuration with Exchange Online Protection is as follows:

After signing-up for Exchange Online Protection you must configure it. The first step is to configure a new domain in the Microsoft 365 Admin Center. When the domain is added and validated it will automatically appear in Exchange Online Protection as an Accepted Domain.

When you click on the domain in the Admin Center it will open another window with the appropriate DNS settings for this domain as shown in the following screenshot (click to enlarge):

Directory Synchronization

It is a Microsoft recommendation to implement directory synchronization using Azure AD Connect when implementing Exchange Online Protection. If you do, all mailboxes in the on-premises Exchange environment are known in EOP as contacts and can be individually managed in EOP.

Inbound mail flow

Before the MX record can be changed to EOP, a Send Connector should be created from EOP to the on-premises Exchange server. This connection is encrypted using TLS, so a 3rd party certificate is recommended.

To create Send Connector from EOP to your on-premises Exchange environment, open the Exchange Admin Center (in Office 365), select mail flow and click connectors. If this is a new EOP environment, you should see nothing.

Click the + icon to add a new connector and in the additional window select Office 365 in the From: dropdown box and select Your organization’s email server in the To: dropdown box as shown in the following screenshot (click to enlarge):

Click Next to continue. In the new Connector windows, give the new connector a name like “EOP to your organization” and click Next to continue. In the following window you have to select when to use this connector. Leave the default radio button on “For email messages sent to all accepted domains in your organization” and click Next to continue. In the next window, specify the name of the host where EOP should deliver all messages to. In my environment this is my Edge Transport server so I enter the FQDN smtphost.exchange2019.nl as shown in the following screenshot (click to enlarge):

Click Next to continue. The following window is about TLS. The default is to enforce TLS and use certificates from a valid third-party CA. Accept the defaults and click Next to continue. The connector is now fully configured, review all settings and click Next to create the connector.

When the connector is created it should be validated. This is to ensure the connector is working as expected and you should do this before making the MX change. Use the + icon to add an email address in the on-premises Exchange environment and click Validate. If the connector is configured correctly, the validation should be successful and the email address you’ve entered will have received a validation message (click to enlarge)

The connector is now ready for use. After changing the MX record in public DNS to the FQDN as found in the Office 365 Admin Center (which is something like yourdomain-com.mail.protection.outlook.com) inbound mail will now be protected by Exchange Online Protection.

When sending an email from Gmail to my Exchange environment and checking the header of the received message it is clearly visible that mail flow is now via Exchange Online Protection (click to enlarge):

Summary

In this blogpost I’ve shown you how to implement Exchange Online Protection as a message hygiene solution in front of your on-premises Exchange environment. The process will be similar if you are using a different mail solution but want to implement EOP before your solution.
In part II I will explain the steps when you want to implement EOP for outbound messaging.