I had to integrate Exchange Online with an on-premise DLP system for one of my customers. The goal was that all messages delivered to the Internet must go through a deployed on-premise DLP server.

By default, even if a classical hybrid is deployed, all messages sent to the Internet by cloud mailboxes are delivered by Exchange Online directly to the recipient server. To achieve my goal, I had to override the standard logic.

The logic had to be:

1. A user with a mailbox in the Exchange Online organization sends a message to an external Internet recipient.
2. Exchange Online is configured to send all Internet-bound messages to an on-premises server, so the message is routed to an on-premises Exchange server.
3. The on-premises Exchange server sends the message to the internal DLP system.
4. The internal DLP system checks and forwards all the messages to an internal mail gateway.
5. The internal mail gateway looks up the MX record for the recipient domain and sends the message to the recipient’s mail servers on the Internet.

The centralized mail transport option can help with this; this option can be enabled during HCW setup.

With centralized mail transport, you can route all mail from mailboxes in the Exchange Online organization through the on-premises organization before they’re delivered to the Internet.

Everything looks perfect, but when I enabled this feature, messages from On-premise to Cloud mailboxes stopped being delivered. Emails sent between Exchange Online and Exchange 2016 were moving until Loop Detection triggered and blocked the email by creating an NDR.

We turned off the centralized transport option, and the mail was delivered without issues. Troubleshooting, we saw that all emails transferred from the local network to Exchange Online had in the header:

X-MS-Exchange-Organization-AuthAs: Anonymous

This meant only one thing: Exchange Online did not recognize these messages as internal and sent them back to Exchange On-Premise before delivery. In my case, loop detection was triggered, the messages were discarded, and an NDR message was generated stating they could not be delivered.

After investigating the problem, one idea was that the certificate used for the connectors needed to be selected correctly. Initially, a self-signed certificate was selected. Since a wildcard certificate was already installed on the server, we did the following:

1) Started HCW and chose to update certificates, then selected the wildcard from the commercial center.
2) Enabled the centralized transport function again.

The transport loop problem disappeared, and messages were labeled as internal. What conclusion can be made? If you enable centralized transport and have issues with delivery:

1) Check the delivery logs; you may have an error about the loop.
2) In that case, turn off centralized transport and see how the messages are recognized.

It should be fixed if you see X-MS-Exchange-Organization-AuthAs: Anonymous in the headers. In my case, it was the self-signed certificate, but I found an article where the certificate’s subject was the route reason for the loops.

Ilia Rud