Why Opportunistic TLS and Mail Security Need Your Attention

Opportunistic TLS is the standard configuration for mail transport security on all Message Transfer Agents (MTA) and mail servers. Sending and receiving mail servers will negotiate with each other which encryption they both are able to use. The most secure connection both parties can handle will be used. This means that mail can sent out with no encryption at all. But you can change that.
Rant: Did we forgot mail security?
It’s weird that we are hardening our operating systems and are worried about how Microsoft Teams is secured. Sometimes we also blame the proverbial intern for any databreach (which is wrong btw). But when it comes to mail, organizations are quite lacking with setting up proper mail authentication. This is the whole SPF, DKIM, DMARC, SRS and ARC stuff, I keep pushing on my socials. There is especially room for improvement when the organizational domain is used in third-party mailing products.
Message Encryption
Sure, you can sign or encrypt your email with S/MIME, PGP or Microsoft Purview Mail Encryption. This means that the individual mail message has been encrypted, unrelated on how it is transported. But IMHO those are not that user friendly. You need to prior setup such as getting certificates and exchange keys. Message encryption provides security but it often conflicts with compliance processes (retention/archiving for instance). Purview provides only protection on the sending side (for new mails).
Yes, there are gateway solutions but that will often increase cost drastically (licenses per seat, maintenance etc.). The visible and hidden cost per email will rise with each addition. Several reasons mail is an attractive solution is the high adoption rate and compatibility. It also relatively easy to use and has a relatively low cost with almost immediate delivery. (To be fair, the economics of mail is an educated guess. It’s good enough and was first are probably also big reasons).
Transport Encryption
Don’t get me wrong. Message encryption certainly has its use cases. I feel like it sometimes prevents thinking about other solutions or practices. Such as, should I even mail this valuable piece of information if it would need message encryption? Is mail actually the best way to safely communicate?
Although I started with Message Encryption, Transport Encryption is actually the primary and implicit form of encryption. Meaning that currently there is almost always transport encryption in place, due to Opportunistic TLS. In most tenants I check, the No TLS bracket is in the 1% range. And this 1% “chance” can be a reason for an organization to utilize Message Encryption, mitigating potential gaps with Transport Encryption and preventing message interception.
Alternativly partner organizations utilize Mandatory TLS connections. These are setup in order to ensure transport encryption is present before sending any mail. It often also has a form of authentication by IP or certificate. The issue I see is that these require a specific configuration and setup per mail domain, which add costs and sometimes requires contact with a peer in order to communicate the correct SMTP endpoint. MTA-STS is an improvement as that it somewhat prevents Advisary-in-the-Middle attacks, as it publishes the MX endpoint in a configuration file on a secure website with the same organizational domain.
The best transport security solution by far is DANE. It provides even more security than Mandatory TLS, as it relies heavily on DNSSEC. Unfortunatly not all organizations are able to use DNSSEC. (Azure DNS had it in preview, but that label is gone?). Especially when Exchange Online will support Mandatory DANE later in 2025. This will force DANE on a tenant or domain basis and allows no downgrades to MTA-STS or Opportunistic TLS. No need for Mandatory TLS or even routing via secure private networks.
But both MTA-STS and DANE suffer from the same problems the other acronyms which is adoption. Sometimes due to technical reasons, but more than not due to knowing or understanding their benefits compared to what is default. Which is Opportunistic TLS.
Forcing TLS in Exchange Online
And after this rant I really want, nay need an answer to this question: why do we still allow Opportunistic TLS to downgrade to unencrypted mail transport? If we can’t all do fancy DANE connections, could we at least look at that? Microsoft actually mentions that it is possible to force TLS on all incoming and outgoing mail using connectors, but does not tell you how exactly. I however do just that.
In order to force TLS on the default SMTP connection, you need to setup both an Inbound and an Outbound connector. The basic Exchange Online PowerShell oneliners are in their simplest form (without performing validation):
New-OutboundConnector -ConnectorType Partner -RecipientDomains * -TlsSettings EncryptionOnly -UseMXRecord $True -Name "Outbound Forced TLS"
New-InboundConnector -ConnectorType Partner -SenderDomains * -TlsSettings EncryptionOnly
There are three main takeaways: the connector type is Partner. You configure the Recipient and Sender domains with a wildcard *. And the final part is to only encrypt and not to validate the certificate. More specific Connectors (such as those with IPs and/or FQDNs) will overrule these connectors. You can have specific connectors not requiring TLS, in case you need it for direct send or SMTP relay.
If your organization prioritizes receiving mail before transport encryption, you could consider starting with an outbound connector first. Combined with an mail queue alert or the use of built-in message reports, you can monitor the situation and act accordingly.
A more holistic approach to (mail) security
I think my main point is that organizations should regularly check their whole approach on how they share information with other parties. Mail is easy and almost always already present. But in the last few years other products are available or improved to such a state that it might be the best solutions for the job. It might also be cheaper, easier to manage and even safer.
I would focus on transport encryption, such as forcing TLS and adopting both MTA-STS and DANE. Especially (Mandatory) DANE is a massive improvement and could be a reason to reevaluate the use of Message Encryption in certain scenarios.
Let me know your thoughts on this subject. Did you enforce TLS or do you have any blocking issues? How do you feel about Message Encryption? Are you planning to implement DANE?
To conclude I wanted to share this marvelous quote by the character Ian Malcolm from Jurrasic Park.
