Advanced Office 365 Routing: Locking Down Exchange On-Premises when MX points to Office 365
Published Feb 15 2019 07:53 AM 73.8K Views

We often get request from customers to control mail flow routing in a hybrid deployment, for various compliance requirements. Achieving the desired routing greatly depends on where the MX record is pointed to and the involvement of 3rd party mail gateways. Also, use of Centralized Mail Transport and the two mandatory Office 365 native domains - tenant.onmicrosoft.com and tenant.mail.onmicrosoft.com may make it even more complex. In this article, we will discuss the scenario, which is recommended for most hybrid organizations, where MX is pointed to EOP and customer wants to restrict their on-premises Exchange servers to only accept emails from their own Office 365 tenant. Before we start, we highly recommend that you go through the following articles to understand the basics of Hybrid mail flow:

hybmailflow1 The above diagram shows mail routing for contoso.com. Their MX record is pointed to Office365. This means on-premises Exchange servers are not supposed to receive external emails directly. Inbound email to Contoso’s On-premises servers will always originate from or relay through their Office 365 tenant. Contoso wants to block direct email delivery from other Office 365 tenants like fabricam.com to their on-premises Exchange Servers, because that would bypass policies and rules created on their Office 365 tenant. In a hybrid Setup, mail from Exchange Online will be received by the on-premises Exchange server either by the Default Frontend Receive Connector or the “Inbound from Office 365” receive Connector created by hybrid configuration wizard. By default, “Inbound from Office 365” Receive Connector will have all Office 365 IP Address ranges as allowed Remote IP Range. Or, in case of the Frontend Receive connector, it will be open to all IPs (0.0.0.0-255.255.255.255). Perhaps it goes without saying, but if your MX record points to Office 365, you definitely don’t want to allow anonymous submissions via the on-premises receive connector. But it’s not as simple as disabling anonymous permission on the receive connector. For Exchange 2010 server, disabling anonymous permission on “Inbound from Office 365” receive connector would cause “5.7.1 Client was not authenticated” NDR for emails coming from even your own Tenant. Whereas, for Exchange 2013 onwards, it works inversely, disabling anonymous permission does not block email from your tenant and for that matter, emails from other tenants are also allowed. So, disabling anonymous permission is not enough to lock down the on-premises Exchange server to only accept emails from your own Office 365 tenant. The concern with this configuration is: any Office 365 tenant who knows external hostname/IP address of your server can send emails to your on-premises servers directly. I want to clarify here that although our on-premises receive connector allows all Exchange Online IP Addresses to submit emails, mails sent from other tenants will not be an authenticated submission and they wouldn’t be able to relay through your on-premises server or be treated as internal to your organization. The emails from other tenants will have the X-MS-Exchange-Organization-AuthAs header set to “Anonymous”. Still, customers might want to go further than this to restrict other tenants to send emails directly to their on-premises environment to avoid various compliance issues. One obvious example is that you may have DLP rules configured inside of your Office 365 tenant, so sending email directly to your on-premises server would bypass that rule. First, let’s try to understand the difference between the situations when mail is sent from your own tenant and mail is sent from other tenants. When email is sent from or relayed through your own tenant, Exchange Online will send XOORG SMTP command extension with the “MAIL FROM” Command which will be extracted from the sender’s P2 or P1 if it’s an accepted domain. In cases where the sender is external (like forward scenario) the XOORG use the default accepted domain. The following two conditions are checked on the on-premises Server:

  1. If the Receive connector TlsDomainCapabilities is set to AcceptedCloudServicesMail, and
  2. If the XOORG Domain mentioned with MAIL FROM Command matches on-premises Accepted Domain or matches any remote domains with TrustedMailInboundEnabled set to true.

If the above conditions are true, on-premises server will treat the connection as Authenticated and will promote cross premises headers to org headers. The protocol log collected from on-premises server for an email received from Hotmail and relayed through Contoso tenant will look something like below-

2018-11-09T16:30:50.288Z,E161\Default Frontend E161,08D61A879C5AB8C3,13,192.168.2.52:25,4.4.0.1:29143,<,MAIL FROM:<someuser@hotmail.com> SIZE=22396 AUTH=<> XOORG=contoso.com,
2018-11-09T16:30:50.289Z,E161\Default Frontend E161,08D61A879C5AB8C3,14,192.168.2.52:25,4.4.0.1:29143,*,SMTPAcceptAnyRecipient SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit,Granted Mail Item Permissions
2018-11-09T16:30:50.289Z,E161\Default Frontend E161,08D61A879C5AB8C3,15,192.168.2.52:25,4.4.0.1:29143,*,08D61A879C5AB8C3;2018-11-09T16:30:48.725Z;1,receiving message
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,16,192.168.2.52:25,4.4.0.1:29143,<,RCPT TO:John@contoso.com,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,17,192.168.2.52:25,4.4.0.1:29143,>,250 2.1.0 Sender OK,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,18,192.168.2.52:25,4.4.0.1:29143,>,250 2.1.5 Recipient OK,
2018-11-09T16:30:50.538Z,E161\Default Frontend E161,08D61A879C5AB8C3,19,192.168.2.52:25,4.4.0.1:29143,<,BDAT 11393 LAST,
2018-11-09T16:30:50.789Z,E161\Default Frontend E161,08D61A879C5AB8C3,20,192.168.2.52:25,4.4.0.1:29143,*,,Set mail item OORG to 'contoso.com' based on 'MAIL FROM:'

Also, this will make sure that all emails directly sent from or relayed through EOP have the “X-OriginatorOrg” header set to your Verified Domain in EXO. So, the email will have the following header:

X-OriginatorOrg: contoso.com

All of this is setup for you by the Hybrid Configuration Wizard, and as long as Office 365 is connecting directly to your on-premises Exchange server(s), XOORG SMTP command is how we keep things secure – you only trust your Office 365 tenant, not others. In fact, because the XOORG command is only understood by Exchange, we say it is more secure to connect Office 365 directly to Exchange or Exchange Edge. Other application layer filtering devices, etc. do not understand XOORG, cannot pass it, and you actually end up in a less secure state. Emails directly sent from other tenants to on-premises servers will also use the XOORG SMTP Extension and will have the X-OriginatorOrg header, but it will not match with your Accepted domain or Remote domain with TrustedMailInboundEnabled. They are still allowed by default into your on-premises Exchange environment because we must allow other possible routing configurations. Can someone spoof XOORG? The answer is “no”, the XOORG headers cannot be spoofed because it is the combination of the EOP TLS certificate, connector setting and accepted domain – and we control the headers when they pass through us, which is the case when our certificate is used.

Note: X-MS-Exchange-Organization-AuthAs header stamped on email received by on-premises server from O365 can be either “Internal” or “Anonymous”. For instance, emails sent from your EXO tenant to on-premises servers, will have the X-MS-Exchange-Organization-AuthAs set to “Internal”. If it’s an external email which is relayed through your tenant, the original “Anonymous” identity would be preserved and the X-MS-Exchange-Organization-AuthAs will be set to “Anonymous”. Thus, X-MS-Exchange-Organization-AuthAs header would not differentiate between email coming directly to your on-premises and email relayed through your tenant.

How to make sure other Office 365 tenants can’t bypass intended routing

Now we know how to differentiate between emails from your own tenant and from others. XOORG validation and X-OriginatorOrg header is the key. You can create a transport rule on your on-premises organization to forward these messages for approval (if X-OriginatorOrg header is not stamped correctly, because these emails are not received through your Office 365 tenant). Alternately, you can generate incident report or redirect these emails to someone else for investigation. This way, you will know if there are valid emails which are coming directly to your on-premises server because of some configuration issues. For example, it might be an internal application sending emails directly on your in-house servers.

AdvRouting2.jpg

Once you identify these issues and decide if you’re ready to take more drastic measures, you can tweak the rule to reject instead of redirect or forward:

AdvRouting03.jpg

The “RejectMessageReasonText” parameter (equivalent to the action “Reject the message with the explanation…”) does not work in Edge server. For Edge Server, you can use other similar parameters like “SmtpRejectMessageRejectText” or “RedirectMessageTo” or “DeleteMessage:$true”.

Now anyone who tries to send emails directly to your on-premises server bypassing your MX record (which points to EOP) will receive the following non-delivery report:

hybmailflow4 The rule will function similarly in all scenarios, whether centralized mail transport is enabled or not. There is one more slightly different routing scenario which we want to cover in this article. Imagine MX for contoso.com is pointed to a 3rd party email filter which forwards the email to their on-premises Exchange server. And then based on recipient’s mailbox location, it can either be delivered locally or forwarded to Office 365. So although the routing is different, we have a very similar issue as mentioned earlier, that any Office 365 tenant who knows external hostname/IP address of your server can send emails to your on-premises server directly. hybmailflow5 Stopping those emails using the Transport rule described above won’t work because inbound emails from internet through the 3rd party device won’t have the X-OriginatorOrg header and all those valid emails will be blocked too. Now, looking at the above diagram, and from our earlier discussion, we can make following assumptions for an inbound email to the on-premises server:

  1. Inbound email from internet will have IP Address of the 3rd party email filter in the receive header if it’s correctly routed through the MX.
  2. In hybrid mail flow, email from your own tenant contoso.com is considered as sent from “Inside the organization”.
  3. Email from other tenants like fabrikam will be treated as anonymous email from “Outside the organization”.
  4. Email from your tenant (Including calendar delegation forward meetings, OOF etc) will always have the “X-OriginatorOrg” header set to your Verified Domain in EXO (or the onmicrosoft domain depending on sender’s Primary address).

So, based on the above assumptions, we can create the following rule to block email which is sent directly to on-premises server bypassing the 3rd party filter. In this example, 192.168.2.51 is the IP address of your 3rd party email filter.

Newrule.jpg We hope this post will be helpful in planning your hybrid mailflow. I also want to take a moment and thank Scott Landry, Daniel Talbot, Lou Mandich, Denis Vilaca Signorelli and Ramon Infante for their contributions.

Arindam Thokder

25 Comments
Co-Authors
Version history
Last update:
‎Aug 17 2022 02:20 PM
Updated by: