How to Set Up MTA-STS and TLS Reporting to Identify and Fix Email Security Issues

Home How to Set Up MTA-STS and TLS Reporting to Identify and Fix Email Security Issues

How to Set Up MTA-STS and TLS Reporting to Identify and Fix Email Security Issues

20th Feb 2024 MTA-STS TLS Reporting

This tutorial provides step-by-step instructions on how to set up MTA-STS and TLS reporting with DMARCLY.

What is MTA-STS

MTA-STS, short for Mail Transfer Agent - Strict Transport Security, is a technology that allows email servers to declare the ability to receive Transport Layer Security (TLS) connections and specify whether sending SMTP servers should refuse to deliver to email servers that do not implement TLS with a trusted server certificate.

Why you need MTA-STS

A man-in-the-middle (MiTM) attack is a cyberattack where the attacker secretly intercepts the messages between two parties and possibly alter them. Attackers can use MiTM attacks to steal sensitive information like login credentials, bank accounts, or corrupt data, by relaying traffic between the sender and the receiver.

STARTTLS can be used to turn a plain text SMTP connection into an encrypted one whenever TLS is supported on the receiving server ("Opportunistic" TLS). However, it's still susceptible to MiTM attacks in that the STARTTLS command can be overwritten by the attacker, unnoticed by the receiving server.

With MTA-STS, a domain administrator can dictate that email servers that support MTA-STS will not send emails to their domain via an unencrypted connection. This makes MiTM attacks much harder to conduct.

How to set up MTA-STS

In order to set up MTA-STS, first you need to create a TXT record on _mta-sts.your-domain to indicate that your domain supports MTA-STS:

_mta-sts.your-domain IN TXT "v=STSv1; id=12345678"

In the record value v=STSv1; id=12345678 above:

the v tag must be STSv1, the protocol literal;
the id tag contains an alphanumeric string up to 32 alphanumerics long, used to track policy (see below) updates; it must uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the id of a previously seen policy.

You can log in to the dashboard, go to DNS Records/MTA-STS & TLS-RPT, and you will find such a record, as shown below:

MTA-STS Record

Simply click the green button as illustrated above to copy the record to the clipboard, then publish it in the DNS.

Next you need to create an MTA-STS policy as follows:

version: STSv1
mode: testing
mx: your-email-host
max_age: 86400

In the policy above:

version must be STSv1;
mode can be enforce, testing, or none:
- enforce mode: the sending server must not deliver the message to a receiving host that fails MX matching or certificate validation or that does not support STARTTLS;
- testing mode: the sending server delivers the message; if TLS reporting is implemented, the sending server also sends a TLS report to the specified email addresses indicating policy application failure, when the receiving host fails MX matching or certificate validation or does not support STARTTLS;
- none mode: the sending server treats the policy domain as though it does not have any active policy;
mx points to one of your MX hosts; multiple mx key/value pairs are possible;
max_age is the max lifetime of the policy in seconds, 31557600 maximum.

Modify the mx value in the MTA-STS policy based on your own MX settings. For example, if your domain's MX record points to: your-email-server.com, you need to update the policy to:

version: STSv1
mode: testing
mx: your-email-server.com
max_age: 86400

If your domain has multiple MX records, create multiple mx key/value pairs in the policy:

version: STSv1
mode: testing
mx: your-email-server.com
mx: another-email-server.com
max_age: 86400

Once the policy looks good, save it in a txt file mta-sts.txt somewhere on your computer.

Next we need to host the MTA-STS policy file so that it becomes accessible for all on the internet at:

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

You need to take the following 2 steps:

create an mta-sts subdomain on your-domain in the DNS;
create a .well-known directory under your web root; then copy mta-sts.txt to .well-known/.

Once this is done, ensure the MTA-STS policy file is accessible by navigating to the following url in your favorite browser:

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

Please make sure to set up the SSL certificate correctly on your web server, so that https://mta-sts.your-domain/.well-known/mta-sts.txt is accessible via HTTPS, not HTTP. Self-signed certificates won't work.

If you are able to see the policy in the browser without any SSL/TLS warning, the policy is probably correctly hosted.

Also, make sure the server returns an HTTP 200 status code from that url. That is, there must not be any redirect. The url in the browser is a good indicator of this. You should see the following url in Chrome once the page is loaded:

mta-sts-policy-url

instead of:

mta-sts-policy-url-redirect

If your MTA-STS url contains a redirect, the MTA-STS checker will indicate the error:

MTA-STS HTTP Status Code not 200

Why you need TLS Reporting

Now that you have MTA-STS in place, you can implement TLS Reporting (TLS-RPT) to receive TLS aggregate reports. With TLS aggregate reports, you can identify email security issues and take action to fix them as necessary.

How to set up TLS Reporting

Setting up TLS reporting is a matter of publishing a TXT record on your domain as follows:

_smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

In the record value v=TLSRPTv1; rua=mailto:[email protected] above:

the v tag must be TLSRPTv1, the protocol literal;
the rua tag points to a comma-separated list of email addresses where TLS aggregate reports are to be submitted.

When you sign up with DMARCLY, a mailbox is created for you in our system to receive TLS reports. Log in to the dashboard, go to DNS Records/MTA-STS & TLS-RPT, and you will find the TLS-RPT record pointing to that mailbox, as shown below:

Default TLS-RPT Record

Keep in mind you will need to use the value shown in your dashboard, instead of the one in the screenshot above.

Once you've completed the above steps, you can use our free MTA-STS checker to make sure things are set up correctly.

After you have published the TLS record with the rua tag set to that mailbox, DMARCLY will start receiving TLS reports on your behalf. These reports are usually sent daily, therefore DMARCLY should have them ready a couple of days after you publish the TLS record.

Here is a TLS report example in JSON format:

{
   "organization-name":"Google Inc.",
   "date-range":{
      "start-datetime":"2021-05-20T00:00:00Z",
      "end-datetime":"2021-05-20T23:59:59Z"
   },
   "contact-info":"[email protected]",
   "report-id":"2021-05-20T00:00:00Z_acme.com",
   "policies":[
      {
         "policy":{
            "policy-type":"sts",
            "policy-string":[
               "version: STSv1",
               "mode: testing",
               "mx: acme.com",
               "max_age: 86400"
            ],
            "policy-domain":"acme.com"
         },
         "summary":{
            "total-successful-session-count":0,
            "total-failure-session-count":3
         },
         "failure-details":[
            {
               "result-type":"validation-failure",
               "sending-mta-ip":"209.85.222.201",
               "receiving-ip":"173.212.201.41",
               "receiving-mx-hostname":"acme.com",
               "failed-session-count":2
            },
            {
               "result-type":"validation-failure",
               "sending-mta-ip":"209.85.208.176",
               "receiving-ip":"173.212.201.41",
               "receiving-mx-hostname":"acme.com",
               "failed-session-count":1
            }
         ]
      }
   ]
}

The following is what TLS report data looks like in the DMARCLY dashboard:

TLS Aggregate Report Example