Part of Ongoing Effort to Improve Email Security
On February 2, Microsoft announced support for SMTP MTA Strict Transport Security (MTA-STS) in Exchange Online. Defined in RFC8461, MTA-STS is is a mechanism enabling “mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.” Like the recent introduction of DANE and DNSSEC support for outbound email, enabling MTA-STS is part of an ongoing effort to improve email security for Exchange Online. In this case, MTA-STS makes it harder for attackers to divert email and ensure that TLS encryption is used for all connections between servers.
Enabling MTA-STS
MTA-STS is enabled for Exchange Online, but If an organization wants to use the capability, they must publish a TXT record in DNS to declare that this is the case and publish their MTA-STS policy in a text file in a well-known location accessible by HTTPS within their domain (Microsoft’s policy is at https://mta-sts.microsoft.com/.well-known/mta-sts.txt). The policy file contains key pairs to define the version, the mode (enforce means that the domain uses MTA-STS; the other values are testing and none), the mx record for your domain, and the maximum lifetime of the policy in seconds.
Microsoft says that organizations which use Exchange Online to process email can use the same values as appear in their policy. For instance, the mx value is *.mail.protection.outlook.com. TLS 1.2 is mandatory for MTA-STS, and the certificates used by TLS must be valid. If you use Exchange Online to handle email, this should all be in order. To make sure, or to check that everything’s in place if you use alternate routing, use the free tool available on https://www.checktls.com/. Figure 1 shows that Office365itpros.com (which uses Exchange Online) has a high confidence level. Details of the mx configuration and certificates are available by clicking the Show Detail button.
Once enabled, TLS-RPT reports can be used to track problems with MTA-STS and DANE, notably when failures to send messages occur because of configuration issues.
The Implementation Question
Anything to improve security is a good thing, so should every Microsoft 365 tenant rush to publish their MTA-STS policy? Well, I don’t know. Unlike DKIM, SPF, and DMARC, which are all easily configured in DNS, MTA-STS has a dependency on certificates. Because Microsoft will take care of certificate renewal, the question is easier for those using Exchange Online to process inbound mail. However, the counter-argument is that lapses in certificate management are not unknown, so this is an issue to consider especially when an organization routes inbound email through a mail hygiene service.
The need to host the MTA-STS policy on a web site shouldn’t be a concern for enterprise tenants, who are likely to have a suitable server to host the policy. Smaller tenants, who perhaps don’t use anything but Microsoft 365, might not. It all depends on the available infrastructure and your security needs.
Deciding not to enable MTA-STS will not stop email flowing because domains which use MTA-STS can communicate quite happily with domains that don’t. The only problems arise when two domains attempt to use MTA-STS only to encounter a problem like an expired certificate.
DANE is the Gold Standard
Microsoft says that DANE is “the gold standard for securing SMTP connections” and MTA-STS is a “lighter-weight mechanism to secure your mail flow”. Today, DANE supports outbound email from Exchange Online with inbound support scheduled for December 2022. In the interim, Microsoft notes that many customers might find MTA-STS “good enough for their security needs.” DANE and MTA-STS can be used together, so there’s no reason for tenants not to implement MTA-STS while waiting for inbound DANE support to arrive.
As for the on-premises world, Microsoft stated that they wouldn’t bring DANE and DNSSEC support to Exchange Server. Given this position, I doubt that MTA-STS will arrive on an on-premises server near you anytime soon, if ever.
Love the MTA-STS. But I am not aware of any means of collecting statistics on it (like the number per x amount of emails secure with MTA-STS. I would settle for even being able to tell from an email header if MTA-STS was used, but I haven’t seen any means of collecting this information. Any ideas?
I think you’d probably need to get at the SMTP logs to detect the MTA-STS information, but they are inaccessible in Exchange Online.
I’m getting tired of MSFT giving on-prem the shaft. Guess I need to start learning some other on-prem email server.
Or move to the cloud like everyone else…
What a load of bollocks.
Just because everyone is jumping in shark infested waters, doesn’t mean one has to…