Introduction to MTA-STS

MTA-STS, or Mail Transport Agent Strict Transport Security, is a mechanism that lets domain owners enforce secure inbound email delivery.

As a domain owner, you can use MTA-STS to:

• Force the delivery of incoming email messages only over a secure and trusted SMTP connection, overcoming the limitations of STARTTLS.
• Provide the list of MX servers for email delivery over a secure HTTPS connection, reducing the risks that come with DNS hijacking.

MTA-STS is defined by RFC8461 and was published in September 2018 as a Proposed Standard together with TLS Reporting.

Why MTA-STS is needed

Email is transmitted between mail servers with SMTP (Simple Mail Transfer Protocol), a protocol that was designed in the 1980s. By default, SMTP transmits data over an unencrypted TCP connection.

For this reason, in 2002 the Internet Mail Consortium introduced STARTTLS, an extension to SMTP that allows connections to be upgraded to secure connections if both the client and the server support TLS authentication. This is called opportunistic encryption, because if either the client or the server don’t support encryption the connection can still proceed over an insecure channel.

While this is good for backwards compatibility, unfortunately this introduces the risk of downgrade or interception attacks: an attacker can interfere with the STARTTLS negotiation process by inducing the client or the server to believe that the other part doesn’t support TLS.

MTA-STS is a mechanism that allows domain owners to specify what to do when a secure connection cannot be established, i.e. either drop the connection and fail, or proceed but report the issue in a TLS report.

High-level mechanism

Here’s how the delivery of an email works when MTA-STS is enabled:

• The process starts with the discovery of the MTA-STS policy: the sending mail server looks for a TXT record on the _mta-sts subdomain of the destination domain. For example, when you send an email to support@dmarcwise.io, a DNS query is sent for _mta-sts.dmarcwise.io.
• The TXT record contains an id, a short string used to determine when the MTA-STS policy has changed. Senders must fetch the policy again when the id changes.
• The policy itself is fetched via HTTPS from the mta-sts subdomain (notice there’s no _ this time) and a well-known path. In the example above, the policy would be fetched from https://mta-sts.dmarcwise.io/.well-known/mta-sts.txt.
• The sending server reads the MTA-STS policy and checks the list of MX servers contained in it. If the mail server it’s trying to deliver mail to is not included in that list, this is considered a policy validation failure.
• If the MX server is valid according to the policy, but the server doesn’t support STARTTLS, it doesn’t support TLS 1.2 or higher or it doesn’t provide a valid and trusted TLS certificate, this is also considered a validation failure.
• The result of the above evaluation depends on the mode specified in the MTA-STS policy:
  • The enforce mode means that the email must not be delivered.
  • If the mode is testing or none, the message can be delivered as if there were no failures and the sender may produce a TLS report to signal the failure.

MTA-STS discovery

To discover if a recipient mail server implements MTA-STS, the sender only needs to resolve a TXT record.

For example, at DMARCwise we have the following TXT record at _mta-sts.dmarcwise.io:

v=STSv1; id=20250503T115500Z;

The id tag contains a timestamp that is updated every time the policy is changed, but it can in theory be any alphanumeric string.

There must be only one MTA-STS record.

The MTA-STS policy file

If the TXT record is present, the sender knows that the policy file can be fetched from a fixed location on the recipient domain.

As the RFC says:

The policy is […] served via the HTTPS GET method from the fixed “well-known” path of “.well-known/mta-sts.txt” served by the Policy Host. The Policy Host DNS name is constructed by prepending “mta-sts” to the Policy Domain.

So in the example above the HTTPS URL for the MTA-STS policy would be:

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

The file must be served with a content type of text/plain and a status code of 200 (OK). Additionally, redirects (3xx) are not supported, HTTP caching must not be used, and the policy must be served quickly enough to not incur into timeouts (the suggested timeout for clients is one minute).

Here’s an example of an MTA-STS policy file:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 1209600

The possible settings are:

• version, with a fixed value of STSv1 (currently).
• mode, which can be either none, testing or enforce.
• max_age, which determines how long the policy should be cached.
• mx: allowed MX servers. Multiple servers can be specified, as in the example above, and a wildcard (*) prefix can also be used.

Policy modes

The choice of the MTA-STS policy mode determines what a sender should do when a validation failure occurs.

The possible values and their meanings are:

• enforce: the sending server must not deliver the messages.
• testing: the failure is reported in TLS reports but the messages can be delivered as if there were no failures.
• none: the sender should treat the domain as if it didn’t have any policy (useful to remove MTA-STS gracefully, see below).

When the delivery of a message fails due to the enforce mode, the sending server must check if an updated policy is available and should also retry the delivery later.

A typical setup process for MTA-STS involves starting with a mode of testing and then moving to enforce. It’s important to monitor TLS reports to detect delivery issues.

Policy caching

To prevent unnecessary fetches of the MTA-STS policy via HTTPS, a caching mechanism was designed.

First of all, the TXT DNS record, much lighter to query than an HTTPS request, helps discover if a new policy was published just by comparing the id tag value.

Additionally, the MTA-STS policy file contains a max_age field which tells sending servers that the policy can be reused for that period of time.

The value of the max_age field should be «as long as is practical», preferably «in the range of weeks or greater».

However, to prevent attacks to the policy, the sending server should update the policy more often, possibly even daily. As the RFC says:

To mitigate the risk of persistent interference with policy refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively refresh cached policies before they expire; a suggested refresh frequency is once per day.

The cache is also useful to tolerate temporary outages in the delivery of the policy:

If no “live” policy can be discovered via DNS or fetched via HTTPS, but a valid (non-expired) policy exists in the sender’s cache, the sender MUST apply that cached policy.

On the other hand, if no policy can be found in the cache nor it can be fetched, the sender should act as if MTA-STS is not enabled:

If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.

Removing MTA-STS

To avoid unwanted failures due to the policy caching, when a domain wants to opt out from MTA-STS the domain owner should follow the following steps:

• Publish a new policy with mode set to none and a small max_age (e.g. one day).
• Update the TXT record to trigger a refresh of the policy in sending servers.
• When all policies (including previous ones which may have had higher max_age values ) have expired, both the TXT record and the HTTPS endpoint can be safely removed.

Relationship with DANE

A conceptually similar mechanism to MTA-STS is DANE (DNS-Based Authentication of Named Entities), which however requires DNSSEC for authentication, a protocol that is often unavailable or not straightforward to set up.

When both protocols are set up, DANE takes precedence in case of a failure. Here’s what the MTA-STS RFC says about this:

The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.