What is MTA-STS and what is it for?

Last week Google announced that they made email more secure by adopting the new MTA-STS internet standard (RFC8461). A lot of sites published articles about this, some claiming Google made email "ultra secure" and that this new standard would fix everything that is wrong with email.

Most of these articles had comments from people making weird assumptions that they would now have to buy expensive certificates and make difficult and time-consuming alterations to their servers to still be able to exchange email with Google. Some of them even implied that Google is abusing its power to force adoption and that the EU should make an effort to stop them (I'm not making this up).

SMTP MTA Strict Transport Security?

Let me try to explain what SMTP MTA Strict Transport Security (SMTP MTA-STS for short) really does and how it indeed, makes email a bit better. Let's start by explaining how email transport works and dive into the weaknesses.

Whether you use the SMTP server from your internet service provider (ISP) or use a service like Gmail, email is not sent directly from your outbox to the inbox of the recipient. The message is transferred from one server to another. This is done through a protocol known as SMTP.

This SMTP communication between servers can be done with encryption to avoid manipulation or eavesdropping. But pay close attention to the word "can". An attacker could perform a man-in-the-middle (MiTM) attack by deleting parts of the unencrypted communication that initiates the encryption (STARTTLS). By doing so the sending SMTP server thinks that the receiving server does not support encryption and starts sending the message unencrypted. This allows the attacker to read and even manipulate the data.

Another type of attack would be to change the address of the recipient's server altogether by overwriting the resolved MX record (recipient's mail server address). The sending server would just deliver the data to the SMTP server of the attacker. While the communication can than still be encrypted, the received data after transmission is not.

How does MTA-STS work?

MTA-STS is a mechanism that instructs an SMTP server that the communication with the other SMTP server MUST be encrypted and that the domain name on the certificate should match the domain in the policy. It uses a combination of DNS and HTTPS to publish a policy that tells the sending party what to do when an encrypted channel can not be negotiated.


Sound familiar? You're right, it does sound like DANE (DNS-Based Authentication of a Named Entities). DANE and MTA-STS serve the same purpose but DANE requires DNSSEC for DNS authentication while MTA-STS relies on certification authorities. In addition, MTA-STS provides an optional testing-only mode, allowing you to deploy a policy without breaking anything.


Most people agree that DANE is superior to MTA-STS as it is easier to deploy, works with self-signed certificates and does not require MTAs to cache policies. The problem is that not everyone wants to adopt DNSSEC because in some situations this is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap. So, if you are using DNSSEC, you don't have to choose, you can implement both.

Ultra secure?

Unfortunately MTA-STS does not make email secure. Although MTA-STS and DANE make sure that email is exchanged encrypted and the recipient server is verified it does not protect email from someone with access to the servers. Most email is stored in plain-text on servers and can be read by anyone with access to the data files.

I can haz MTA-STS?

If your mail server supports STARTTLS encryption and you've got signed certificates installed in your mail and web server you should definitely publish an MTA-STS policy. No signed certificate yet? You can get them from free by using Let's Encrypt.

Deploy MTA-STS

All you need to do is add two DNS records and a text file in the ".well-known" folder of your domain. The first DNS record to add is a "_mta-sts" TXT record containing the version and an id.

_mta-sts.example.com.	IN	TXT	"v=STSv1; id=20160831085700Z;"

The "id" is used to track policy updates. This allows the sending server to determine when the policy has been updated. The second DNS record is a "mta-sts" (note the lack of the underscore at the beginning) A or CNAME record pointing to the server that is publishing the policy.

The policy should be made available at the following location: "https://mta-sts.example.com/.well-known/mta-sts.txt" and look something like this:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
max_age: 604800

This will let any MTA-STS supporting mail server know that you want them to obey your policy. Note that the "testing" mode does not actually prevent messages from being sent over an unencrypted channel or to a malicious server. If you are confident enough that everything is configured accurately you can change the mode to "enforce".


You can configure the "mode" to be either "enforce", "testing" or "none", indicating the expected behavior of the sending email server in case of a policy validation failure.

  • "enforce": The sending server will not deliver the message to the receiving server.
  • "testing": Messages will be delivered as though there was no failure but a report will be sent if TLS-RPT is configured (see below).
  • "none": Can be used to remove MTA-STS. The server will treat the policy as though it does not have any active policy.


One or more patterns matching allowed MX hosts for your domain. Put each host on a new line with the "mx:" prefix if you have multiple.


This specifies the maximum lifetime of the policy in seconds (maximum value of 31557600). Mail servers will cache your policy up to this value from the last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value typically be in the range of weeks or greater.

* UPDATE: Google will only process policies with a max_age higher than 86000 seconds. Policies with a max_age of 86000 or lower will be ignored and a daily no-policy-found report will be sent if TLS-RPT is enabled (see "Monitoring and reporting" below).

Everything okay?

If you want to test if your policy and DNS records are configured correctly you can test your configuration for free at this great service from Hardenize.

Monitoring and reporting (with uriports)

Just like with DANE you could (and should) use SMTP TLS-RPT to enable mail servers to let you know how your policy is performing and if any violations of your policy have come to pass. This will also keep you posted on expired certificates and other TLS related issues.

Adding TLS-RPT can be done by adding another TXT DNS record containing the rua (aggregate report URI) destination where reports should go to:

_smtp._tls.mail.example.com.	IN	TXT	"v=TLSRPTv1;rua=mailto:tlsrpt@example.uriports.com"

The sending mail server will send you an aggregate report daily containing useful information about all messages they have sent to you. These reports contain a (compressed GZIP) JSON file like this:

     "organization-name": "Company-X",
     "date-range": {
       "start-datetime": "2016-04-01T00:00:00Z",
       "end-datetime": "2016-04-01T23:59:59Z"
     "contact-info": "sts-reporting@company-x.example",
     "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
     "policies": [{
       "policy": {
         "policy-type": "sts",
         "policy-string": ["version: STSv1","mode: testing",
               "mx: *.mail.company-y.example","max_age: 86400"],
         "policy-domain": "company-y.example",
         "mx-host": "*.mail.company-y.example"
       "summary": {
         "total-successful-session-count": 5326,
         "total-failure-session-count": 303
       "failure-details": [{
         "result-type": "certificate-expired",
         "sending-mta-ip": "2001:db8:abcd:0012::1",
         "receiving-mx-hostname": "mx1.mail.company-y.example",
         "failed-session-count": 100
       }, {
         "result-type": "starttls-not-supported",
         "sending-mta-ip": "2001:db8:abcd:0013::1",
         "receiving-mx-hostname": "mx2.mail.company-y.example",
         "receiving-ip": "",
         "failed-session-count": 200,
         "additional-information": "https://reports.company-x.example/
           report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
       }, {
         "result-type": "validation-failure",
         "sending-mta-ip": "",
         "receiving-ip": "",
         "receiving-mx-hostname": "mx-backup.mail.company-y.example",
         "failed-session-count": 3,
         "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"

Reading and interpreting these reports can be a difficult task for a human. Thankfully, we at URIports have got a solution that allows you to easily manage your reports and let you know exactly when something needs your attention.

TLS-RPT monitoring with URIports


The TLS-RPT reports do not contain any content from the email messages themselves and we at URIports do not use any data for anything else than providing you with a clear view of all your reports. Nothing is shared or sold, so your reports are safe with us.