Index

MTA-STS

TL;DR

Mail Transfer Agent Strict Transport Security (MTA-STS) is an email security standard for secure delivery of email to your domain. With MTA-STS you let senders know that your email server accepts secure email delivery using SMTP over TLS (STARTTLS), and that email should not be delivered over an insecure SMTP connection.

MTA-STS mitigates Man-In-The-Middle DNS and SMTP downgrade attacks that would allow an attacker to read or manipulate email in transit.

Why MTA-STS?

When an email is send, the email server (MTA) will determine where to deliver email by querying the MX records of the receiving domain over DNS. For example: an MTA who wants to send an email to example@mailhardener.com will perform a DNS query for the MX records of mailhardener.com to learn to which MTA the email must be send. The MTA then connects to the MTA it found in the DNS query result and negotiate if this MTA supports the STARTTLS command to switch to an encrypted connection. The email is then delivered.

There are two possible vulnerabilities here:

MTA-STS aims to mitigate both vulnerabilities, it is specified in RFC8461.

DNS spoofing attacks

DNS is an unencrypted protocol, for anyone who operates a portion of the internet (like ISPs, governments, public WiFi, etc.) it is trivial to manipulate DNS traffic that flows through the network. By doing so, an attacker replace the MX records in a DNS query response with an email server that they control. This results in the sending MTA delivering the email straight to the attacker controlled email server. Once the attacker has copied or even manipulated the email, it is then forwarded to the real MX for that domain, as if nothing happened.

Because MX records of a domain point to MTAs by name, not IP address, the attacker can use a domain that they control. This enables the attacker to provide a valid certificate, so STARTTLS will not protect against DNS based attacks.

An attack where DNS responses are manipulated is known as a DNS spoofing attack. Attempt have been made to protect against DNS spoofing by introducing zone signing in the DNSSEC (RFC4033) standard. But concerns have been raised about the security and practicality of DNSSEC to a point where some even advice against using DNSSEC.

With MTA-STS, the MX addresses fetched over DNS are compared to those found in the MTA-STS policy file, which is served over a secure HTTPS connection. And because the MTA-STS policy is also stored by the sending MTA, a successful DNS spoofing attack becomes very unlikely.

SMTP downgrade attacks

When the SMTP email protocol was first defined in the early 80's, it did not support encrypted transport of email. Encryption using TLS was later added as the RFC3207 standard, implemented as the STARTTLS SMTP command.

To retain backwards compatibility, the MTAs will negotiate whether STARTTLS is supported by both sides before the command is issued. So, the SMTP session always starts in plain text, and only switches to encrypted communication after the STARTTLS command is issued. Because TLS can also fail in more ways than plain text connections, most MTAs will fall back to plain text if for some reason the TLS connection does not work.

This creates an opportunity for a Man-In-The-Middle attack to block the STARTTLS negotiation or the encrypted communication. This will cause the MTAs to fall back to plain text communication. The attacker can now read the email.

MTA-STS mitigates this attack by allowing the domain owner to publish a policy on the requirement of TLS. By setting the policy to enforce, MTA-STS capable MTAs will only connect using TLS. Of no TLS connection can be established, it will not deliver the email.

How MTA-STS works

Unlike SPF, DKIM and DMARC, the MTA-STS policy is published using HTTPS rather than DNS. HTTPS is not susceptible to MITM attacks like DNS is.

MTA-STS requires an HTTPS enabled web server so serve the policy file, and a DNS TXT type record to indicate that the domain supports MTA-STS, or that a policy change has been made.

A sending MTA will check for the existence of the MTA-STS DNS record at the domain found in the sender address. If the DNS record is found, the sending MTA will fetch the MTA-STS policy file over HTTPS from the web server.

If you run MTA-STS for your domain, you can use our MTA-STS inspector to validate that it is setup correctly.

The MTA-STS policy file

The MTA-STS policy is a text-file that is served using HTTPS. A web server must be set up to serve the policy file at:

https://mta-sts.[domain]/.well-known/mta-sts.txt 

For example: the MTA-STS policy for mailhardener.com can be found at https://mta-sts.mailhardener.com/.well-known/mta-sts.txt

The MTA-STS policy is a text file, which looks like this:

version: STSv1
mode: enforce
mx: mx1.domain.com
mx: mx2.domain.com
max_age: 604800    

The text file is a simple key-value structure where the key and value are separated by a colon. Each key-value pair must be on a separate line. Line separation is allowed in both Windows (\n\r) and UNIX (\n) style. Any other whitespace is ignored.

The options are as follows:

key description
version Must be the first line, and must contain value STSv1 for this policy file to be valid.
mode The TLS requirement policy, see below for details.
mx The email exchange (MX) for this domain. Multiple MXs are allowed, each must be placed on their own line. The MX values in the MTA-STS policy should reflect TLS capable servers that are also in the DNS MX records. The use of wildcards (*) is allowed as the leftmost character.
max_age The time (in seconds) that a MTA is allowed to cache the policy. A well-behaved MTA-STS policy should use a high value here and use the MTA-STS DNS record to signal for policy changes. To minimum recommended value is 1 week (604800 seconds), but preferably it should be higher.

The mode can have one of these values:

mode description
none MTA-STS is disabled for this domain, the none value can be used is situations where a domain used MTA-STS before, but no longer wishes to use it.
testing Also known as monitoring mode, MTA-STS is used, but the sending MTA is allowed to fall back to plain text communication in case of TLS failure. The sender will report the failure over TLS-RPT if enabled.
enforce Sending MTAs are expected to always use TLS when delivering email to this domain. If no TLS secured connection could be established the email will not be delivered. If enabled, the sender will report TLS failures using TLS-RPT.

The MTA-STS DNS record

The MTA-STS DNS record is a DNS record of type TXT that indicates that the domain supports MTA-STS. It is also used to signal MTAs in case the policy is changed and the MTA should refresh the stored value.

An HTTPS fetch requires much more resources (bandwidth, CPU time, memory) than a DNS query. The introduction of MTA-STS would increase the load on MTAs significantly if it has to (attempt to) fetch a policy for every domain it processes email for.

Thus, RFC8461 specifies that a DNS record must used to indicate the support for MTA-STS by the domain. The DNS record is also used to indicate a change in the policy, that would require the MTA to re-fetch the policy over HTTPS.

With the MTA-STS DNS record, the policy can stored by MTAs for a long period (weeks or even months) without requiring a re-fetch. The MTA will still perform the query on the DNS record (respecting the record's TTL value of course) whenever it receives email from the domain, but unless the DNS record is changed the MTA won't re-fetch the policy over HTTPS.

The MTA-STS DNS record is a TXT type record, it must be placed at subdomain _mta-sts (note the underscore). For example: _mta-sts.mailhardener.com.

The text value has a very simple structure:

v=STSv1; id=20190101T000000;

The TXT record must begin with v=STSv1 for it be valid. The id value can be any alphanumeric value with a maximum length of 32 characters.

Whenever the MTA-STS policy is changed, the id value in the TXT record must be updated to a new and unique value, signaling to the MTAs that a new policy was set. The ID value may be set to any alphanumeric value, but it is common to use a timestamp for the ID value.

When using Mailhardener hosted MTA-STS, the MTA-STS record id value is automatically updated whenever a policy change is made.

If you run MTA-STS for your domain, you can use our MTA-STS inspector to validate that it is setup correctly.

TLS reporting

The usage of TLS will introduce new ways that email delivery can fail. Certificates can expire, email servers can be misconfigured or the sender and receiver may not support the same cryptographic standards, just to name a few.

If the MTA-STS policy is set to enforce mode and the TLS connection cannot be established, the email will not be delivered. The sender will retry a couple of times, and should also try a different MX (if the domain has more than one). Ultimately the MTA will return (bounce) the email back to the sender if it can't be delivered over TLS.

A reporting solution was needed to detect and debug situations where senders are unable to deliver email to your domain due to TLS issues. Thus the TLS-RPT standard was introduced as RFC8460.

MTAs that support TLS-RPT will aggregate TLS results, both the successful deliveries and failures, and send those reports to a predetermined email address.

Read more about TLS-RPT

Using MTA-STS

For a domain to use MTA-STS, the domain owner must do the following:

Hosted MTA-STS

As shown in the previous section, setting up MTA-STS involves quite a bit of work, as does maintaining an HTTPS enabled web server.

Mailhardener offers hosted MTA-STS, which will take care of hosting the MTA-STS policy, obtaining and renewing the certificate and automatic updating of the id value in the MTA-STS DNS record if the policy is changed.

Changes to the MTA-STS policy for your domain can be made instantly using the Mailhardener dashboard, no manual editing of DNS records required.

Read more about Mailhardener hosted MTA-STS

MTA-STS preloading

If you are a software developer, you might be familiar with HSTS (HTTP Strict Transport Security), MTA-STS is basically the same as HSTS, but for email.

HSTS comes with a feature called preloading, which is a list of hosts that use HSTS. In HSTS, preloading is aimed to prevent a bootstrapping vulnerability where a browser visiting a domain for the first time does not yet know the domain uses HSTS and thus an attacker could block the HSTS HTTP header upon first visit. The preload list is a list hosts that are known to use HSTS, the list comes pre-bundled with all major browsers.

MTA-STS has a similar bootstrapping problem where the DNS query for the MTA-STS record may be blocked by an attacker. This attack would prevent the MTA from fetching the MTA-STS policy file over HTTPS, and thus allow the MTA to use unencrypted SMTP.

In response to this, the electronic frontier foundation (EFF) has introduced the STARTTLS Everywhere project, which is basically preloading for MTA-STS. If you have your email setup to use MTA-STS, you could submit your domain to STARTTLS everywhere to have it included in the MTA-STS preload list.

FAQ

Who should use MTA-STS?

MTA-STS is suitable for every domain that uses MX servers that support the STARTTLS command. Regardless if this is self-hosted, on premise or cloud hosted. The use of MTA-STS is recommended by all major cloud email providers, since they all support STARTTLS properly.

Which MX servers do I put in the policy file?

The policy file should contain all mail exchange (MX) servers for your domain, that support STARTTLS. These are the addresses that you have set in the MX DNS records of your domain.

Is there risks when using MTA-STS?

If you have set your MTA-STS policy to enforce but your MX fails to serve a valid certificate for it's domain, the email will not be delivered. This is, of course, what MTA-STS is intended to do. The sending MTA will retry delivery at a later time, so intermittent issues with your MX will usually not cause any problems. To monitor delivery issues, you can enable TLS-RPT. When using TLS-RPT with Mailhardener, you will be notified immediately if any delivery error is received.

Further reading

Tools