Review the Header information for TLS, which indicates that the message was delivered using TLS:
Note: Perform this test in the opposite direction to make sure TLS is being used in both directions
Exchange Hosted Services (EHS) front-ends all Microsoft Online Mail and uses Deterministic TLS when sending/receiving messages, which means that it will attempt to send/receive mail via TLS (issuing EHLO statements to understand the message servers capabilities).
On-Premise à TLS à EHS à TLS à Microsoft Online Services
Microsoft Online Services à TLS à EHS à TLS à On-Premise
Note: IF TLS is not available anywhere along this path, delivery will fallback to SMTP port 25 and deliver in clear-text.
If a customer requires full TLS Messaging Transport capabilities, they will need a TRUSTED certificate (a certificate that can be verified and is trusted – Verisign, GoDaddy, etc.) on their On-Premise Exchange Bridgehead Server, so when MS Online/EHS delivers mail, it can properly negotiate the TLS session. ALSO, the On-Premise Exchange Admin must configure their SMTP Connector to use Outbound Security – TLS, in order to request a TLS session for any Address Namespaces (i.e. contoso1.microsoftonline.com) defined for that Connector.
This is great that TLS will be supported.
I am curious though, why won't the MTLS features take effect if a customer has Exchange 2007 on-site?
Also for those customer's who want to have private certificates, is there anything on the roadmap to allow private certs between the on-site email system and Exchange Online?
Hi Josh, EHS does not require a client (sending server) certificate, so we wouldn't do MTLS. EHS provides it's certificate, which is a commonly used certificate, which is trusted by ALL Windows machines. As a result, the sending server is able to successfully able to establish a TLS connection and deliver the message.
When EHS attempts to deliver a message to an On-Premise Messaging server (Coexistence), it will attempt a TLS connection and if enabled on the receiving server AND is using a certificate that can be validated (Not expired, on a CRL and the Common Name matches), then EHS will deliver using TLS.
So that end, private certificates cannot be used when receiving mail from an EHS endpoint over TLS.
I hope this helps