In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:

This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at https://www.gov.uk/guidance/set-up-government-email-services-securely#configure-cloud-or-internet-based-email-services and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:

You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.

MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.

If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.

We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:

And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions: