What is MTA-STS and how is it Implemented?

The SMTP protocol isn’t secure and wasn’t designed to be. Email sent in the early days of the Internet were the digital equivalent of sending a postcard through the postal system. Eventually, Transport Layer Security (TLS) encryption was added to protect SMTP communications. But to maintain backward compatibility, it was never made compulsory and even today it’s used only opportunistically by senders.

MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers. It was designed to patch an existing hole in the STARTTLS protocol. The purpose of MTA-STS is to encrypt and secure communications between SMTP servers via TLS (Transport Layer Security) preventing man-in-the-middle attackers from viewing and manipulating in-transit emails. With MTA-STS you let senders know that your email server accepts secure email delivery using SMTP over TLS, and that email should not be delivered over an insecure SMTP connection. The acronym MTA stands for Message Transfer Agent, which is a program that transfers email messages between computers. The acronym STS stands for Strict Transport Security, which is the protocol used to implement the standard. An MTA-STS-aware mail transfer agent (MTA) or secure message transfer agent (SMTA) operates in accordance with this specification and provides a secure end-to-end channel for sending email over unsecured networks.

While most outgoing emails today are secured with Transport Layer Security (TLS) encryption, an industry standard adopted even by consumer email, attackers can still obstruct and tamper with your email even before it gets encrypted. If you email to transport your emails over a secure connection, your data could be compromised or even modified and tampered with by a cyber attacker. Here is where MTA-STS steps in and fixes this issue, guaranteeing safe transit for your emails as well as successfully mitigating MITM attacks.

Major mail service providers such as Microsoft and Google support MTA-STS. Google’s Gmail has already adopted MTA-STS policies in recent times. MTA-STS has removed the drawbacks in email connection security by making the process of securing connections easy and accessible for supported mail servers.

When an email is sent, the email server (MTA) will determine where to deliver the email to by querying the MX records of the receiving domain over DNS. For example: an MTA which must deliver an email to [email protected] will perform a DNS query for the MX records of mydomain.com to learn which MTA the email must be sent to. The MTA then connects to the MTA it found in the DNS query result and negotiates if this MTA supports the STARTTLS command. If it does, the MTAs switch to an encrypted connection, and the email is then delivered securely.

If the receiver does not support STARTTLS, or the secure connection cannot be established for other reasons, the email is sent using an unencrypted connection.

How To Adopt MTA-STS

MTA-STS allows a domain to declare support for TLS and communicate the MX record and destination certificate to expect. It also indicates what a sending server should do if there’s a problem. This is done through a combination of a DNS TXT record and a policy file that’s published as an HTTPS web page. The HTTPS-protected policy introduces another security protection that attackers must overcome.

A domain's MTA-STS TXT record indicates MTA-STS support to a sender, after which the domain's HTTPS-based MTA-STS policy is retrieved by the sender. The following TXT record is an example that declares support for MTA-STS:

_mta-sts.mydomain.org. 3600 IN?TXT v=STSv1; id=20230201000000Z

A domain's MTA-STS policy is located at a predefined URL that’s hosted by the domain's web infrastructure. The URL syntax is https://mta-sts.<domain name>/.well-known/mta-sts.txt. For example, policy is found at:

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

version: STSv1

mode: enforce

mx: *.mail.mydomain.org

max_age: 604800

Requirements

Ensure you have verified the following prior to deploying MTA-STS.

• Your MX supports SMTP over TLS version 1.2 or later.
• Your server supports SSL (HTTPS)
• Your MX uses a TLS certificate issued by a root certificate authority that is not expired, and matches its?domain name.

When implementing MTA-STS, which requires DNS entries, you should also enable TLS Reporting, which also requires its own DNS entries. By implementing TLS reporting, you will be able to see the performance of your domains and the success/failure rate of your MTA-STS policies. This will give you important insight into which mail senders you need to work with to ensure no interruption in mail flow.

MTA-STS Policy File

The MTA-STS Policy File file is a plain-text file containing a set of the following key/value pairs:

version: The protocol version of the file. At the time of this writing, it must be STSv1.

mode: This is the policy mode. The values available are testing, enforce, or none.

testing: Senders will send your reports (TLSRPT) indicating policy application failures. This requires TLSRPT to also be implemented to work. TLS connection failures will not be blocked, while being able to receive reports.

enforce: Sending mail servers that support MTA STS will not deliver mail to your domain where the certificate authentication fails, or cannot negotiate TLS. Reports on these failures are sent as well.

none: Senders will treat the domain as thought it does not have any active policy. It effectively disables MTA STS.

mx: The MX records for the domain. It has to match the MX records published in your domain’s DNS. You can specify either the FQDN or a wildcard host (mx: mail.example.org or mx: *.example.org). Ensure each MX records are added on their own line in the policy file.?

max_age: The maximum lifetime of the policy expressed in seconds. This represents the length of time a sender would cache the domain’s policy. It is recommended to use a value equivalent of several weeks or greater, but not exceeding 31557600 (roughly 1 year).

Example of policy file:

version: STSv1

mode: testing

mx: mail.mydomain.org

mx: *.mydomain.org

mx: mail2.mydomain.org

max_age: 604800

Once the policy text file is ready, it must be published on the web to be accessed by senders.?

The file must be available at a specific URL on a subdomain of your domain. An example of URL would be:

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

A DNS TXT resource record is needed in order to enable MTA-STS on your domain. This record exists at a unique subdomain:

_mta-sts

For the example.org domain, it would be _mta-sts.mydomain.org.

The TXT record contains 2 key/value pairs.?

“v”?The version of the protocol, which currently only supports the value STSv1.

“id” A string of 1 to 32 alphanumeric characters meant to track policy updates.?This string must be updated every time there is a change made to your MTA-STS policy file. A good practice is to use the date and time of the change to make up the ID number.

An example of such record is as below:

_mta-sts.mydomain.org.?IN TXT “v=STSv1; id=202302012135;”