How to enable MTA-STS in Office 365

SMTP MTA Strict Transport Security (MTA-STS) is a relatively young protocol that allows you to signal the use of trusted certificates when encrypting electronic mail during SMTP transmission.

The transmission of electronic mail uses so-called opportunistic encryption. The client side connects to the server, notifies the server of its intention to encrypt the communication using STARTTLS (RFC 3207) and establishes an anonymous TLS connection, i.e. without authenticating the identity of the counterparty. If anything goes wrong at the beginning of the communication, the client switches to the backup plan and the mail is transmitted unencrypted.

Properly configured mail servers thus only protect the user from passive eavesdropping. If someone has the ability to interfere with the communication in a targeted way, they can affect the traffic by planting their own certificates or blocking encryption altogether. The aforementioned RFC even explicitly states that encryption must not be enforced for the sake of interoperability between servers.

MTA-STS is equivalent to HSTS

In the HTTPS world, the HTTP Strict Transport Security (HSTS) header is now quite common, which signals to the browser that encryption with trusted certificates is mandatory on a given site and that it should remember this information for a specified period of time.

This is exactly the principle that inspired the creators of the MTA-STS protocol. It solves two complementary problems:

it hardwires a domain to its MX servers
enforces a dogmatic encryption policy and authorization with trusted certificates

Deploying MTA-STS in Office 365

The deployment of MTA-STS for Exchange Online in Office 365 needs to be split into two parts:

MTA-STS in Office 365 for outgoing emails

MTA-STS in Office 365 for inbound emails

MTA-STS in Office 365 for outgoing emails

MTA-STS is automatically active for all outgoing mail. This means that for all outgoing mail, the recipient mail server is checked to see if MTA-STS is active on the domain, and if so, the recipient mail server policy is checked and the rules are applied before sending the message.

So, for example, if the recipient’s mail server defines the policy as ENFORCE and the check to establish a secure connection would fail, the email would not be sent to the recipient and an NDR would be returned to the sender.

These settings are automatically active for all tenants and no further action is required.

MTA-STS in Office 365 for inbound emails

MTA-STS must be configured to protect incoming mail.

MTA-STS policy text file

First you need to create a TXT file defining the MTA-STS policy for the domain. This TXT file must be located at a specific URL:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

The above path to the MTA-STS policy TXT file is fixed and cannot be changed.

The content of the file has a defined structure and for Office 365 Exchange Online might look like the following:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Specifically, you can see the MTA-STS defined for my domain here https://mta-sts.cswrld.com/.well-known/mta-sts.txt

MTA-STS DNS record

Once you have a TXT file ready with the policy at the given address, you can create a DNS TXT record for your domain that says that an MTA-STS policy exists for that domain.

Again, this TXT record has a defined form and looks like this:

_mta-sts.yourdomain.com. 3600 IN TXT v=STSv1; id=20230830000000Z;

This TXT record is defined for the subdomain _mta-sts and its value is v=STSv1; id=20230830000000Z;. v=STSv1 is always the same and says that it is STS version 1. id=20230830000000Z; is just an ID and can be anything. Usually it is a date of publishing the record.

Reporting for MTA-STS

Just as DMARC can have reporting set up, so can have reporting set up for MTA-STS as well. This is done using a TXT record on the _smtp._tls subdomain, the value of which might look like this: