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 p...
Updated Aug 17, 2022
Version 4.0
Blog Post
8 MIN READ
Advanced Office 365 Routing: Locking Down Exchange On-Premises when MX points to Office 365
For the last scenario, you will need both possible exceptions, correct? The IP address(es) of the mail gateway and the X-OriginatingOrg with your default tenant domain.
Hello Dustin, for the last scenario, we don't need X-OriginatingOrg exception because mail from your own tenant will be considered as from “Inside the organization”. So mail from your tenant will be exempted anyway.
- We are in the last scenario, MX records point to on premise 3rd party filtering, then routing through on prem to our ExO tenant (we have centralized mailflow). I can tell you from experience (and a case with support) that just adding the IPs is not enough. You'll need to Exempt 'calendaring' message types (or external messages sent to delegates will be blocked as 'external' when delegation sends it to the delegate on behalf of the 'boss'), and exempt messages with headers 'x-ms-exchange-organization-AuthAs' of 'internal' or internal Out of Office messages will be blocked.
- Hello MRI503X, I tested the scenario you explained here, however I am unable to repro this in my lab. I tested few scenarios-
Scenario1-
Meeting is sent from External Domain to a user in tenant1 (say user1). User1 forwarded the Meeting to tenant2 whose MX is pointed to 3rd Party. I see the email is sent to 3rd party itself and not directly to tenant2. So the IP Address of 3rd party will be there in the header and the email won’t be blocked by the rule (because of IP exception)
Scenario2-
Meeting is Sent from External Domain to tenant1 (say user1). User1 on behalf of his manager forward the e-mail to an On-Prem user. Here the Auth-AS header is set to Internal. Again the email won’t be blocked by the rule (because the rule is only for external email, internal mails are bypassed)
Did I miss the scenario? Could you please explain the exact problem scenario so that I can do more testing in my lab?
- Hi Arindam,
Some info on our environment and then I will confirm the scenario:
-Exchange 2016 Hybrid mode. All user mailboxes in cloud.
-We have "Centralized Mailflow" enabled. My understanding now of what this really does, is a process in the tenant look at a message during transport, and if it hasn't come from on prem, it's sent on prem (even user to user - cloud hosted mb to cloud hosted mb)
-Our MX records point to an on premise SMTP relay.
-These relays pass email to our on premise Exchange servers, which then transfer it to the tenant.
Scenario:
-All users are in the same cloud tenant. Boss1 had delegate User1. Boss1 has set up his delegation such that notices are forwarded/copied to the Delegate (user1).
-Boss1 gets a meeting invitation from user2 (a tenant mailbox user) and delegation forwards on to user1. User1 receives it.
-Boss1 gets a meeting invitation from an external sender, and his delegation configuration forwards it to user1. User1 does not receive the message.
-For User1 to get these messages, we had to add an exception to the transport rule of "Is message type 'Calendaring'"
- Yes this is a pretty botched up scenario and organizations have started taking notice of this design flow and microsofts response of getting this fixed using transport rules has been pretty flawed. They have the source and destination code control and it would be good if they put some engineering on this.
This fix does not work when:
1. Senders with calendar delegation forward meetings.
2. Senders that are on O365 hybrid but are striping their headers for security concerns.