Securing the Hybrid receive connector further

A customer raised a security question the other week about the hybrid receive connector on the On Premises Exchange server. In short he asked “what’s to stop someone creating a send connector on their own 365 tenant to send directly to his hybrid server?” – Well, That’s a very good question.

To secure the mail flow from Office 365 to the On Premises Exchange we request that customers allow the Exchange Online Protection IP addresses through their firewall on Port 25. That’s all very well and good, and we (and most others think nothing more about it once done). It wasn’t until we had that very question ourselves we actually thought “yeah, what is there to stop someone creating a send connector in their own tenant to another companies hybrid server?”

We did the usual, had a chat about it and threw a few ideas in the hat, and initially certificates were decided the best avenue to explore. But, the certificates are on the Microsoft end are managed by Microsoft so there is not much we can do there.

We then thought, lets ask Microsoft, but they could not help us (there a surprise!). Their response “Its by design”, typical!

We then thought about a transport rule?

I was in the middle of re-building my Exchange lab in Azure so I thought this was going to be a perfect opportunity to test the Transport Rule theory.

So, the first thing I thought I would check was the headers. I checked the headers of 3 types of messages:

  1. External email to my Exchange lab
  2. My Office 365 lab to my Exchange lab
  3. My main Office 365 account to my Exchange Lab

A little bit of background to my lab mail flow.

My MX Records point to Mimecast. And that has a delivery route to deliver to my Exchange lab, which then routes up to Office 365. I’d run the Hybrid Configuration in my Office 365/Exchange lab so I had all the connectors in place. And finally my main Office 365 account was sending to via the public MX Records of

The headers were all as expected. But the header that caught my eye was on the the email that was sent via the hybrid connector that was built by the HCW. and the X-OriginatorOrg header:


The other two message headers did not have this header.

I then created a Send connector in my “production” Office 365 tenant where I run my email address from.

when I then analysed the message headers I noticed it then had an X-OriginatorOrg header:


So that go me thinking. What about creating a Transport Rule that would delete all emails from “Outside” the Organisation with an Exception of the header includes


I then tested an email from the lab 365 tenant ( and my main Office 365 tenant ( via the scoped send conenctor.

I received the validation email from my lab Office 365 tenant but not my main Office 365 tenant. Job’s a good’un! Well its half way there.

I then tried sending a test email using the Send-MailMessage CMDLet to simulate sending an email from an anonymous user which is how Multifunctional Devices work.  As that anonymous and not listed as “internal” traffic as it originated outside the Exchange Organisation. And guess what? the email was not received.

So, my first thought was to add another exception based on the received header including the IP Address of the network to allow the emails through, but, that would effective reverse the “block rule” for any emails from senders who have that same network… Now lets face it, a lot of people will be using a 192.168.X.X, 10.X.X.X or 172.16.X.X subnets so there would still be some risk there, as any one doing this from a subnet the same as my lab subnet would still be allowed through. So I decided to try it with an exception of the “Senders Domain”:


This seemed to do the trick. So all good? No

I tested from the 3 sources again:

  1. External email to my Exchange lab
  2. My Office 365 lab to my Exchange lab
  3. My main Office 365 account to my Exchange Lab (with a direct send connector)

Emails from external to my lab were not received, emails from my Office 365 lab to my Exchange lab were received and emails from my mail Office 365 tenant to my Exchange lab were not received. Not great as external email was being deleted too. Again I thought exception in the Received headers? Nope, that would allow emails through from other Office 365 send connectors if they are using the same subnet as me. The only fix I could think of is route external email from Mimecast to Office 365 to then route to On Premises, rather than Mimecast to On Premises then on to Office 365. You’ll be pleased to know that actually Worked Smile.


Whilst there maybe some other things to consider, especially if its a larger enterprise, it does seem possible to block your hybrid server from receiving email from other Office 365 tenants, but this way may cause more work and administration in the long run and you may need to add more exceptions than I have depending on your infrastructure. IT will also mean from the outset all external email will need to be routed through Office 365 initially to deliver to On Premises and not routing to On Premises initially and then on to Office 365. I you use an On Premises appliance for filtering email then this will not work, however I would always recommend companies (especially large enterprises) to run a dual cloud environment with Office 365 and have something sitting in front of Office 365.

I’d certainly be keen to see if there are any other ways to secure the Hybrid received connector to receive emails from only your own tenant.

Leave Comment

Your email address will not be published. Required fields are marked *