MTA-STS: Why You Need It, How It Works

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism that enforces TLS encryption for inbound email delivery to a domain. It enables mail servers to securely communicate by ensuring messages are transmitted over an encrypted connection, thereby mitigating risks such as man-in-the-middle attacks.

In 2019, Google became the first major email provider to adopt the new MTA-STS policy, which ensures all inbound emails come through the Transport Layer Security (TLS). This policy complements and strengthens STARTTLS, which is a command that allows mail servers to upgrade an SMTP connection to a secure, encrypted one. The issue with STARTTLS is that it is vulnerable to downgrade attacks and lacks mechanisms for strict enforcement or sender authentication, making it optional and insecure in certain scenarios.

The MTA-STS policy aims to prevent attackers from tampering with email content or sending the communication to another address. Unlike STARTTLS, MTA Strict Transport Security always keeps TLS on. It tells external servers that your email server only accepts email delivery through a secure connection.

Why Do You Need this Email Protocol?

The MTA-STS DNS policy, coupled with TLS reports, is a reliable way to make your email communications more secure. Here is what the policy does:

• Hinders downgrade attacks
• Removes the risk of man-in-the-middle (MITM) attacks
• Solves the issue of expired TLS certificates

TLS-RPT, like DMARC reports, provides details on successes and failures, keeping you informed and ready to make fixes

The Importance of TLS Reporting

TLS Reporting (TLS-RPT) is a protocol that allows email domains to receive reports about the success or failure of TLS encryption during email transmission, providing insights into potential security issues when emails are sent to a domain.

Like DMARC reports, TLS reports detail failed SMTP connections and explain why they happened. The failures occur for three  reasons:

• Failed TLS negotiation
• DNS-related issues
• MTA-STS problems

Also, like DMARC reports, TLS reports are delivered to a particular URI (Uniform Resource Identifier) or email address set up via a DNS TXT record.

Here is the DNS record string: 

“v=TLSRPTv1; rua=mailto:[email protected],https://tlsrpt.example.com/v1”

The string contains:

• The TLS version (“v=”)
• The URI (Uniform Resource Identifier) that’s going to receive the reports (“rua=”). This line can take more than one value separated by a comma.

The TLS Report Structure

Unlike DMARC XML reports, TLS Reporting is easy to read and understand. The report file is in JSON format.

The table below explains the components of a TLS Report shown in the image above.

Components of TLS Report
organization-name	Name of the reporting party
date-range	Timeframe for the collected results containing the start and end dates as a subcategory
contact-info	Contact information
report-id	Unique report identifier
policies	This section contains information about the various active policies for the given domain (STARTTLS, DANE, DNSSEC, MTA-STS). In the case of MTA-STS, for example, this section will repeat the policy file string
summary	Provides the session count for successful and failed sessions
failure-details	Mentions what went wrong. The “result type” can take one of the 10+ set values, depending on the failure’s root cause. This line also includes information on the sending server, receiving IP, and its MX hostname

How Does MTA-STS Work?

MTA-STS is a policy that verifies the TLS connection on every email sent to your ecosystem. It tells the sending SMTP server that communication with your email server must be encrypted, and the domain name in the TLS certificate and the policy must match. This process ensures that all communication delivered to your inbox is encrypted.

The policy contains a two-part mechanism: The MTA-STS file published on an HTTPS-enabled web server, and a DNS TXT record telling senders that your domain supports MTA-STS.

Once everything is set, you’ll receive reports via TLS-RPT about failures and issues. Sending servers cache the MTA-STS file and use it repeatedly for a period indicated in the document. Upon expiration, the servers request the file again.

Let’s dive further into the two components of the MTA-STS policy.

The MTA-STS File

MTA-STS is a TXT file executed through HTTPS.

The table below explains the components of an MTA-STS file shown in the image above.

Components of MTA-STS File	Description	Options/Details
version	The version of the policy file you’re viewing	The proper syntax is to include this line first, with the other components following in any order
mode	The policy mode	The policy mode can take either of the values below: testing: The messages that fail to pass the TLS won’t be blocked, but you’ll be able to gather data on them (similar to the DMARC quarantine policy). Enable TLS-RPT to start getting the reports. enforce: Failing the TLS means that the emails won’t be delivered (similar to the DMARC reject policy). However, you’ll still receive reports. none: While the modes above are somewhat comparable to DMARC policies, this one is very distinct. The ‘none’ policy in your MTA-STS file means fully disabling the policy.
mx	To fill in this part, you have to pull your MX records from the DNS	Mention each mail host on a separate line to nail the syntax of the file
max_age	Indicates how long the sender should cache the policy	The number is expressed in seconds and should be: between 604,800 and 1,209,600 (1–2 weeks) for testing mode between 24 hours (86,400 seconds) and 31,557,600 (one year) for enforce mode

The MTA-STS DNS Record

For senders to “know” you have implemented the MTA-STS policy, you have to set up a DNS record. It points to the policy file and contains the following components:

• “v=:” This is the policy version number.
• “id=:” This is the policy identification number and should change once the policy is updated.

What are the Requirements for MTA-STS?

Before starting the MTA-STS setup, you need to check specific requirements, as not every server can handle the MTA Strict Transport Security policy. These requirements are:

• Can accept mail transfers via TLS connection
• Uses at least TLS version 1.2
• The TLS certificates should:
  • Be up-to-date
  • Have the same servers mentioned in your MX records
  • Be trusted by a root certificate authority

Implement Your MTA-STS Policy

Setting up your MTA-STS DNS policy is relatively straightforward. But however important it is to reach the coveted “enforce” policy mode, advancing the mode from “testing” takes time and focus.

Here are the steps to take before creating the DNS record and the MTA-STS file itself:

• List all the domains and subdomains you plan to protect.
• Use a TLS checker to discover any issues with its configuration.
• Ensure that the certificates are up-to-date and TLS is on the 1.2 version or higher.
• Make sure your server supports the Secure Socket Layer Certificate (SSL). HTTP won’t cut it – you need HTTPS.
• Use a holistic solution to ease your way into policy compliance.

Now that you’re all set, begin the three-step implementation process:

Step 1. Create the Policy in Testing Mode

First of all, create the MTA-STS policy file. Follow the syntax above. Set the mode to “testing” initially to see how the policy performs.

Step 2. Upload the TXT File to the WEB

Ensure the file is accessible on the WEB upon request so senders can find it once the DNS record points to it. The URL should follow this syntax:

https://mta-sts.example.com/.well-known/mta-sts.txt

This means that you should create a “.well-known” folder and put the document there.

Step 3. Publish the DNS Record

Publish the DNS Record, confirm it, and move to the next phase, TLS configuration.

Step 4. Set up the TLS-RPT

Create the DNS TLS entry as mentioned above and start receiving the reports. Don’t forget that this is an MTA-STS test. Once you see everything working correctly, you can move to the next step.

Step 5. Change the Mode to “Enforce”

After this initial MTA-STS test, if everything runs smoothly, you can set the “mode” in the MTA-STS file to “enforce.” This will filter unencrypted emails.

Step 6. Update the Version ID in Your DNS Record

As the last step, don’t forget to update the DNS with the new version ID.

Of course, these steps are simplified with EasyDMARC’s  Managed MTA-STS tool.

Summary

Implementing MTA-STS strengthens your email security by ensuring encrypted communication and protecting against man-in-the-middle attacks. Combining the MTA-STS policy with TLS Reporting gives you valuable insights into potential issues while preventing unauthorized email delivery. Although setting up MTA-STS requires careful planning and testing, the long-term benefits – enhanced security, better compliance, and reduced vulnerabilities – make it a vital tool for any organization. Start with testing mode, address any configuration issues, and gradually move to enforcement to secure your email ecosystem effectively. If you’re unsure, contact one of our DMARC engineers.