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:
2018-11-09T16:30:50.288Z,E161\Default Frontend E161,08D61A879C5AB8C3,13,192.168.2.52:25,220.127.116.11:29143,<,MAIL FROM:<email@example.com> SIZE=22396 AUTH=<> XOORG=contoso.com,
2018-11-09T16:30:50.289Z,E161\Default Frontend E161,08D61A879C5AB8C3,14,192.168.2.52:25,18.104.22.168: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,22.214.171.124: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,126.96.36.199:29143,<,RCPT TO:John@contoso.com,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,17,192.168.2.52:25,188.8.131.52:29143,>,250 2.1.0 Sender OK,
2018-11-09T16:30:50.290Z,E161\Default Frontend E161,08D61A879C5AB8C3,18,192.168.2.52:25,184.108.40.206:29143,>,250 2.1.5 Recipient OK,
2018-11-09T16:30:50.538Z,E161\Default Frontend E161,08D61A879C5AB8C3,19,192.168.2.52:25,220.127.116.11:29143,<,BDAT 11393 LAST,
2018-11-09T16:30:50.789Z,E161\Default Frontend E161,08D61A879C5AB8C3,20,192.168.2.52:25,18.104.22.168:29143,*,,Set mail item OORG to 'contoso.com' based on 'MAIL FROM:'
X-OriginatorOrg: contoso.comAll 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.