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:126.96.36.199 -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):
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):
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.
10 thoughts on “Implementing Exchange Online Protection for on-premises Exchange Part I”
Hi Jaap, I’m considering this for a customer with Exchange 2016, they have no ADConnect yet, but IF I do, would it require me to consider the Exchange already as a Hybrid server, because if I ADsync and I do not filter out the mailboxguid property, then O365 will “think” I want to go hybrid. But later, if I wish to migrate (using bittitan migrationwiz for example) and decomission (on condition I do some Powershell export/import to fool ADsync), Im not stuck on users that can’t get a coud mailbox because it assumes I need to transfer them via Hybrid. So in your example above, did you have to go hybrid or not? There is no mail license required, it’s just for EOP and rather would keep the option to smoothly be able to get rid of the last Exchange in due time. Thanks for reading 🙂
Hi Werner, there’s a difference between Azure AD Connect and Exchange hybrid. When you install Azure AD Connect in your environment, Azure AD and Exchange Online Protection will detect the users as being on-premises mailboxes, that’s all. But if I read your email correctly, you will run into issues when you want to migrate data using BitTitan because a mailbox cannot be active both on-premises and online.
I was using this for testing Exchange on-premises, so I only had Azure AD Connect and EOP licenses, and thus with all mailboxes on-premises. Later on you can create a hybrid scenario and move your mailboxes using hybrid (and forget about BT in this scenario).
Thank you for your swift feedback. It makes me wonder however if I have to sync that mailboxguid so EOP can in fact detect there is an onpremise mailbox, or if I can exclude it from sync so I don’t run into trouble if I choose not to go the hybrid way. Guess I’ll probably exclude first, see what happens and then decide that I’m forced to go hybrid or not.
Don’t worry too much about the mailbox GUID. It’s the recipient type that determines if it shows up as a mailbox or a mail-enabled user. Unless you mess up completely (as in beyond repair) you run into trouble, no need to worry at this point
Thanks for the article, Jaap, this was exactly what I was looking for yesterday…! 😉 Now, another question: currently, we use a 3rd party anti-spam and anti-phishing solution for our customers. For the real small number of them that still have Exchange Servers on-premise, we’re considering to switch to Exchange Online Protection. In the current situation, we have whitelisted the IP’s from the 3rd party, we only allow them to use TCP 25 to deliver inbound mail. When we switch to EOP, EOP will be the delivering party to the Exchange Server. Now, given that we do not want to open TCP 25 to the entire world, how do we know which IP’s MS uses to deliver mail (using the Connector that you illustrated above)?
Thanks for the article, Jaap, this was exactly what I was looking for yesterday…! 😉
Now, another question: currently, we use a 3rd party anti-spam and anti-phishing solution for our customers. For the real small number of them that still have Exchange Servers on-premise, we’re considering to switch to Exchange Online Protection. In the current situation, we have whitelisted the IP’s from the 3rd party, we only allow them to use TCP 25 to deliver inbound mail. When we switch to EOP, EOP will be the delivering party
to the Exchange Server. Now, given that we do not want to open TCP 25 to the entire world, how do we know which IP’s MS uses to deliver mail (using the Connector that you
sorry for my late reply, I was not feeling well the last two weeks.
Have a look at this article: https://learn.microsoft.com/en-gb/microsoft-365/enterprise/urls-and-ip-address-ranges
This lists the Microsoft IP ranges used per service/protocol
Jaap, Thank for your response! The link you mention lists various range of IP addresses of Microsoft endpoints that should be reachable from a client’s perspective. But, in this scenario, it’s the other way around: EOP needs to have access to the on-prem XCH server. Would you say that line 10 (about SMTP) is the one we should use?
Yes, this is both ways
OK, thanks, Jaap, excellent. Going to try/test this!