What is MTA-STS, and Why Do You Need It?

Hardening your email security is a multi-step process. We’ve been talking about outgoing email security for a while now, and that’s what DMARC is for. However, many domain owners are still concerned about incoming email security.

In 2019, Google adopted the new MTA-STS policy that ensures all inbound emails come through the Transport Layer Security (TLS). The latter is a cryptographic protocol that encrypts communications. The need for this new policy arose from and addresses its predecessor’s weaknesses. 

STARTTLS is a command that asks the mail server to encrypt the connection. However, the problem with it is that it’s an optional measure. Plus, it doesn’t allow sending server authentication, which makes the command susceptible to MITM attacks.

Now that the need for policy change is clear, let’s dive into what MTA-STS is and how it works.

What is MTA-STS?

Mail Transfer Agent-Strict Transport Security (MTA-STS) is a mail protocol that encrypts inbound emails with a secure layer. This allows for TLS-encrypted communication between SMTP servers, which in its turn prevents man-in-the-middle attacks.

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 sending servers that your email server only accepts email delivery through a secured connection.

Why Do You Need MTA-STS and TLS Reporting?

As you might understand, there’s no such thing as 100% cybersecurity. The internet is full of bad actors who look to improve and expand their attacks based on whatever new policy or protocol comes next. They never stop.

Still, new protocols always bring something to the table. The MTA-STS DNS policy coupled with TLS reports is a reliable way to make your email communications a bit more secure. Here is what the policy does:

• Hinders downgrade attacks
• Removes the risk of MITM attacks
• Solves the issue of expired TLS certificates

TLS is there to keep you updated on failure reports and fixes you can make.

What is SMTP TLS Reporting?

We wrote another in-depth article a while back, explaining Simple Mail Transfer Protocol (SMTP) and Transport Layer Security (TLS), so you might be familiar with how it works and what TLS reports are.

Now, it’s time to dip your toes into what TLS reporting means for servers with MTA Strict Transport Security. Essentially, if the policy is set to “enforce” and the TLS connection fails, the email will not be delivered to your inbox. After a few more tries, the email will bounce (go back to the sender).

But how do you know how many connections failed? The TLS reports are just that poke to inform you about emails that passed and failed.

Like in the DMARC reports, TLS reports on failed connections and points to why they happened. The failures might occur for three general reasons:

• Failed TLS negotiation
• DNS-related issues
• MTA-STS problems
• Like DMARC reports, TLS reports are delivered to a particular URI (Uniform Resource Identifier) set up via a DNS TXT record.

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.

Here is the DNS record string: 

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

The TLS Report Structure

Unlike DMARC XML reports, SMTP TLS Reporting is easy to read and understand. The report file is in JSON format, and here are some of the components you’ll see in it:

• report-id: The unique report identifier.
• date-range: The timeframe for the collected results containing the start and end dates as a subcategory.
• organization-name: The name of the reporting party.
• contact-info: The contact information.
• policies: This section might contain 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 (more about the file and its syntax below).
• summary: This section wraps things up by giving you the session count for successful and failed sessions.
• failure-details: And finally, this part 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 sending server, receiving IP, and its MX hostname. Finally, you’ll be able to confirm the failure count again.

Still, moving it to a human-readable format is preferable. {Here is what EasyDMARC came up with}.

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 match. As we described above, 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.

Now that you understand the basic principles, let’s dive further into the two components of the MTA-STS policy.

The MTA-STS File

As we’ve already discussed, MTA-STS is a TXT file executed through HTTPS. Let’s see what it contains. As you might probably guess, although it’s a plain TXT file, it should have a specific syntax so that the sending server can “read and interpret it.” The file contains the following components:

• version: What version of the policy file you’re viewing. The proper syntax is to include this line first. Other components can follow in any order.
• mode: This is the policy mode. It can take 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. Enable TLS-RPT to start getting the reports. (Acts much like the quarantine policy in DMARC, doesn’t it?) 
• enforce: In this mode, 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: This component 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; and between 24 hours (86,400 seconds) and 31,557,600 (one year) for enforce mode.
• The MTA-STS DNS Record

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

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

What are the Requirements for MTA-STS?

Not every server can handle the MTA Strict Transport Security policy. Here are a few requirements to check before starting the setup:

• 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, advancing the mode from “testing” takes utmost attention (otherwise, you might miss a bunch of crucial emails from important senders).

Below are a couple of 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 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 File

First of all, create the MTA-STS policy file. Follow the syntax we talked about above. Set the mode to “testing” first 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 the 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

We’ve talked about this simple DNS command above. Just publish it, confirm, 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.

Summary

EasyDMARC has always been about protection. DMARC protects your company internally and externally. Still, inbound communication security is an ongoing issue. The MTA-STS policy is taking yet another step to stop hackers from eavesdropping, communication tampering, and downgrading attacks.

With MTA-STS explained, we leave it to you to explore the new tools and processes. Don’t rush, don’t move to “enforce” too soon, and be thorough.

The journey to secure email is sometimes overwhelming, and you must be meticulous and technical. However, nothing beats the peace of mind once you see the mechanisms working for you.