In our previous article we discussed enforced TLS with Exchange. More precisely with on-premises Exchange servers. We established that Exchange uses opportunistic TLS, meaning it prefers encryption but it is not enforced if the other party only supports plain SMTP traffic. In this article we take a look on setting up enforced TLS between our Office365 Exchange tenant and a partner organization. Our domain is alwayshotcafe.com just like before. The chosen partner is opentechtips.com.
Prepare for Forced TLS in Office365
The process is very similar to the earlier discussed way, only naming changed a little. When administering Exchange Online we don't have "Send" and "Receive" connectors per se, we simply have "Connectors". We can set the direction - the from-to sides - during setup. This means that we configure two connectors: one for inbound, one for outbound connections.
1. Force inbound TLS
First, we set up a specific inbound connector that only accepts emails from the partner, opentechtips.com if the emails are encrypted.
PS:
using ECP:
2. Set up the Outbound connector
Then we configure the outbound connector. The process is the same, only the direction is swapped. With PowerShell we use the New-OutboundConnector cmdlet. If the WebUI is preferred, the steps are the same only the direction differs. As before, we use MX record routing, and enforce TLS without validating the domain.
PS:
with ECP:
The direction is reversed, this time it is for messages from our tenant to the partner.
All Done Now only encrypted SMTP traffic is allowed between us (alwayshotcafe.com) and opentechtips.com. If opentechtips tried to use a 3rd party mail service that only supports plain SMTP, our tenant will reject those emails, protecting the likely private material in them form eavesdroppers. Likewise our tenant will refuse to send outgoing emails towards opentechtips.com, if the receiving party doesn't support encrypted traffic.
Comments