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 the inbound email service for your domain 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.
When an email is sent, the sending email service (MTA) will determine where to deliver the email to by querying the DNS for the MX records of the receiving domain.
For example: an MTA which must deliver an email to example@mailhardener.com will perform a DNS query for the MX records of mailhardener.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.
There are two Man-In-The-Middle (MITM) attacks possible here:
MX query, tricking the sending MTA to deliver email to an MTA controlled by the attacker. This is known as a DNS spoofing attack.STARTTLS negotiation could be disrupted, tricking the sending MTA into sending the email without the use of TLS encryption. This is known as a downgrade attack.Both attacks result in the attacker being able to read and manipulate the email while it is being sent.
MTA-STS aims to mitigate both vulnerabilities, it is specified in RFC8461.
DNS is an unencrypted protocol, for anyone who operates a portion of the internet (like ISPs, governments, public Wi-Fi, etc.) it is trivial to manipulate DNS traffic that flows through the network.
By doing so, an attacker can replace the MX records in a DNS query response with an email service that they control.
This results in the sending MTA delivering the email straight to the attacker controlled email host.
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. Attempts 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 advise 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 policies are also cached by MTAs, a successful DNS spoofing attack becomes very unlikely.
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. This policy can be set to enforce the use of TLS, so that MTA-STS capable MTAs will only deliver email over an encrypted connection.
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 webservice to 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 webservice.
If you run MTA-STS for your domain, you can use our MTA-STS validator to validate that it is set up correctly.
The MTA-STS policy is a text-file that is served using HTTPS. A webservice 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 services 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. The 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 in 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 SMTP TLS reporting if enabled. |
enforce |
Sending MTAs are expected to always use TLS when delivering email to this domain. If no secure TLS connection could be established the email will not be delivered. If enabled, the sender will report TLS failures using SMTP TLS reporting. |
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 be 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 be 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 to 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 validator to validate that it is set up correctly.
If a domain indicates it is using MTA-STS by publishing the MTA-STS DNS assertion record, but the MTA-STS policy cannot be fetched from the policy service, then the sender should continue delivery as if the domain does not use MTA-STS. In other words: A failure in the MTA-STS policy service should not result in the domain becoming unable to receive email, but will (eventually) leave the domain vulnerable again to SMTP TLS downgrade attacks.
Senders will cache the MTA-STS policy for a prolonged time (determined by the max_age property in the policy), typically for 1 to 2 weeks.
So temporary outages of the MTA-STS policy service typically don't leave the domain vulnerable, unless the sender has not fetched the policy before, or has removed the policy from its cache.
The usage of TLS will introduce new ways that email delivery can fail. Certificates can expire, email services 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, but the sender fails to establish a TLS connection with the SMTP service, then it won't deliver the email (as it should be).
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 SMTP TLS reporting standard was introduced as RFC8460.
MTAs that support SMTP TLS reporting will aggregate TLS results, both the successful deliveries and failures, and send those reports to a predetermined email address.
Read more about SMTP TLS reporting
For a domain to use MTA-STS, the domain owner must do the following:
A or CNAME type DNS record at mta-sts.[domain] pointing to the HTTPS enabled webservice serving the MTA-STS policy file.TXT or CNAME type DNS record at _mta-sts.[domain] indicating the use of MTA-STS, and update the id value on policy change.mta-sts.[domain] that serves the MTA-STS policy file.TXT or CNAME record placed at _smtp._tls.[domain].As shown in the previous section, setting up MTA-STS involves quite a bit of work, and so does maintaining the HTTPS enabled webservice.
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
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 of 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 set up to use MTA-STS, you could submit your domain to STARTTLS everywhere to have it included in the MTA-STS preload list.
If MTA-STS needs to be disabled completely for a domain that uses MTA-STS, then a procedure must be followed in order to prevent potential deliverability issues.
noneTXT record at _mta-sts.domain.tld) to signal to senders that the policy has changed. (note: when using Mailhardener hosted MTA-STS, this happens automatically).max_age specified in the MTA-STS policy (typically 2 weeks).max_age cool-down period) it is safe to remove the DNS entries for MTA-STS (mta-sts.domain.tld and _mta-sts.domain.tld). Do not remove the DNS records without following these steps, or you risk email not being delivered to the domain.
It may be tempting to lower the max_age value, but this will not reduce the cooldown period, as senders can have cached to original max_age value.
MTA-STS is suitable for every domain that uses MX services 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.
The policy file should contain all mail exchange (MX) hosts for your domain that support STARTTLS.
These are the addresses that you have set in the MX DNS records of your domain.
If you have set your MTA-STS policy to enforce but your MX fails to serve a valid certificate for its 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, it is recommended to use SMTP tls reporting.
When using SMTP TLS reporting with Mailhardener, you will be notified immediately if any delivery error is received.
On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.
You can also follow and reach us on X @Mailhardener.