What is MTA-STS? Setup the Right MTA STS Policy

A widely known internet standard that facilitates improving the security of connections between SMTP (Simple Mail Transfer Protocol) servers is the SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS). MTA-STS resolves existing problems in SMTP email security by enforcing TLS encryption in transit. Encryption is optional in SMTP which implies that emails can be sent in plaintext. MTA-STS enables mail service providers to enforce Transport Layer Security (TLS) to secure SMTP connections, and to specify whether the sending SMTP servers should refuse to deliver emails to MX hosts that do not support TLS with a reliable server certificate. It has been proven to successfully mitigate TLS downgrade attacks and Man-In-The-Middle (MITM) attacks.

The History and Origin of MTA-STS 

In the year 1982, SMTP was first specified and it did not contain any mechanism for providing security at the transport level to secure communications between the mail transfer agents. However, in 1999, the STARTTLS command was added to SMTP that in turn supported the encryption of emails between the servers, providing the ability to convert a non-secure connection into a secure one that is encrypted using TLS protocol.

In that case, you must be wondering if SMTP adopted STARTTLS to secure connections between servers, why was the shift to MTA-STS required, and what it even did. Let’s jump into that in the following sections of this blog!

Simplify Security with PowerDMARC!

What is MTA-STS? (Mail Transfer Agent Strict Transport Security – Explained)

MTA-STS stands for Mail Transfer Agent – Strict Transport Security. It is a security standard that ensures the secure transmission of emails over an encrypted SMTP connection. The acronym MTA stands for Message Transfer Agent, which is a program that transfers email messages between computers. The acronym STS stands for Strict Transport Security, which is the protocol used to implement the standard. An MTA-STS-aware mail transfer agent (MTA) or secure message transfer agent (SMTA) operates in accordance with this specification and provides a secure end-to-end channel for sending email over unsecured networks.

The MTA-STS protocol allows an SMTP client to verify server identity and ensure that it is not connecting to an impostor by requiring the server to provide its certificate fingerprint in the TLS handshake. The client then verifies the certificate against a trust store containing certificates of known servers.

Introduction of MTA-STS Email Security 

MTA-STS was introduced to bridge the gap in security during SMTP communications. As a security standard, MTA-STS ensures the secure transmission of emails over an encrypted SMTP connection.

The acronym MTA stands for Message Transfer Agent, which is a program that transfers email messages between computers. The acronym STS stands for Strict Transport Security, which is the protocol used to implement the standard. An MTA-STS-aware mail transfer agent (MTA) or secure message transfer agent (SMTA) operates in accordance with this specification and provides a secure end-to-end channel for sending email over unsecured networks.

The MTA-STS protocol allows an SMTP client to verify server identity and ensure that it is not connecting to an impostor by requiring the server to provide its certificate fingerprint in the TLS handshake. The client then verifies the certificate against a trust store containing certificates of known servers.

The Need for Shifting to Enforced TLS Encryption

STARTTLS was not perfect, and it failed to address two major problems: the first being that it is an optional measure, hence STARTTLS fails to prevent man-in-the-middle (MITM) attacks. This is because an MITM attacker can easily modify a connection and prevent the encryption update from taking place. The second problem with it is that even if STARTTLS is implemented, there is no way to authenticate the identity of the sending server as SMTP mail servers do not validate certificates.

While most outgoing emails today are secured with Transport Layer Security (TLS) encryption, an industry standard adopted even by consumer email, attackers can still obstruct and tamper with your email even before it gets encrypted. Since security had to be retrofitted in SMTP to make sure it was backward compatible by adding the STARTTLS command to initiate TLS encryption, in case the client doesn’t support TLS the communication falls back to cleartext. This way emails in transit can fall prey to pervasive monitoring attacks like MITM, wherein cybercriminals can eavesdrop on your messages, and alter and tamper with information by replacing or deleting the encryption command (STARTTLS), making the communication roll back to plaintext. A MITM attacker can simply replace the STARTTLS with a garbage string that the client fails to identify. Therefore, the client readily falls back to sending the email in plaintext. If you fail to transport your emails over a secure connection, your data could be compromised or even modified and tampered with by a cyber attacker.

Here is where MTA-STS steps in and fixes this issue, guaranteeing safe transit for your emails as well as successfully mitigating MITM attacks. MTA-STS enforces the emails to be transferred over a TLS encrypted pathway, and in case an encrypted connection cannot be established the email is not delivered at all, instead of being delivered in cleartext. Furthermore, MTAs store MTA-STS policy files, making it more difficult for attackers to launch a DNS spoofing attack. The primary goal is to improve transport-level security during SMTP communication and ensuring the privacy of email traffic. Moreover, encryption of inbound and outbound messages enhances information security, using cryptography to safeguard electronic information.

Set Up MTA-STS with PowerDMARC!

How Does MTA-STS Work?

MTA-STS protocol is deployed by having a DNS record that specifies that a mail server can fetch a policy file from a specific subdomain. This policy file is fetched via HTTPS and authenticated with certificates, along with the list of names of the recipient’s mail servers. Implementing MTA-STS is easier on the recipient’s side in comparison to the sending side as it requires to be supported by the mail server software. While some mail servers support MTA-STS, such as PostFix, not all do. MTA-STS allows servers to indicate that they support TLS, which will allow them to fail close (i.e. not sending the email) if the TLS upgrade negotiation doesn’t take place, thereby making it impossible for a TLS downgrade attack to take place.

Major mail service providers such as Microsoft, Oath, and Google support MTA-STS. Google’s Gmail has already adopted MTA-STS policies in recent times. MTA-STS has removed the drawbacks in email connection security by making the process of securing connections easy and accessible for supported mail servers.

Connections from the users to the mail servers are usually protected and encrypted with TLS protocol, however, despite that there was an existing lack of security in the connections between mail servers before the implementation of MTA-STS. With a rise in awareness about email security in recent times and support from major mail providers worldwide, the majority of server connections are expected to be encrypted in the near future. Moreover, MTA-STS effectively ensures that cybercriminals on the networks are unable to read email content.

The MTA-STS Policy File

The MTA-STS policy file is a plain-text MTA-STS configuration file that is hosted on a domain’s web server under an HTTPS URL: It defines rules for establishing secure connections between mail servers, enforcing TLS encryption, and specifying actions to take if a secure connection cannot be established. 

https://mta-sts.<domain>//.well-known/mta-sts.txt

Structure of MTA-STS Policy File 

MTA-STS Policy Example

version: STSv1 

mode: enforce 

mx: mail.example.com 

mx: backupmail.example.com 

max_age: 86400

Prerequisites for MTA-STS Deployment

Before you get started with your MTA-STS setup, you need the following: 

1. A Registered Domain Name 
2. Valid TLS Certificates

• TLS certificates must be issued by a trusted CA
• Certificates must be up-to-date and not expired
• Should be at least a TLS version 1.2 or higher 

3. A DNS TXT record for MTA-STS 
4. HTTPS web server 
5. Mail server configured to use TLS 
6. Mail server hostname matching the entries in the mx field of your policy file
7. A testing environment or hosted MTA-STS service to monitor logs and make adjustments whenever necessary

Steps to Set Up MTA-STS for Your Domain

In order to set up MTA-STS for your domain you can follow the steps shown below: 

• Check if your domain has existing MTA-STS configurations. If you are using Google Workspace for your emails you can do so easily with the help of this guide. 
• Create and publish an MTA-STS policy, configured separately for each domain. The MTA-STS policy file defines MTA-STS-enabled email servers used by that domain. 
• Upon creating your policy file, you must upload this file to a public web server which can be easily accessed by remote servers 
• Finally, create and publish your MTA-STS DNS record (“_mta-sts” TXT record) to instruct receiving servers that your emails must be TLS-encrypted to be considered authentic, and should only be allowed access to your receiver’s inbox if the former is true

Once you have an active policy file, external mail servers will not allow access to email without a secure connection. 

3 MTA-STS Policy Modes: None, Testing and Enforce

The three available values for MTA-STS policy modes are as follows: 

1. None: This policy nullifies your MTA-STS configuration as external servers will consider the protocol inactive for the domain 
2. Testing: While on this policy, emails transferred over an unencrypted connection will not be rejected, instead, with TLS-RPT enabled you will continue to receive TLS reports on the delivery path and email behavior
3. Enforce: Finally, when on enforce policy emails transferred over an unencrypted SMTP connection will be rejected by your server. 

MTA-STS offers protection against :

• Downgrade attacks
• Man-In-The-Middle attacks (MITM)
• It solves multiple SMTP security problems, including expired TLS certificates, lack of support for secure protocols, and certificates that are not issued by reliable third parties.

TLS Reporting: Monitoring Email Deliverability Gaps Post MTA-STS Setup 

TLS-RPT (Transport Layer Security Reporting) is a protocol allowing domain owners to receive detailed reports on TLS encryption failures in email communications. TLS Reporting works in conjunction with MTA-STS. It enables the reporting of issues in TLS connectivity that is experienced by applications that send emails and detect misconfigurations. It enables the reporting of email delivery issues that take place when an email isn’t encrypted with TLS. In September 2018 the standard was first documented in RFC 8460.

Key Features include: 

• Error reporting: It provided detailed reports on delivery issues or failures caused by TLS issues such as expired certificates or outdated TLS versions, and TLS encryption failures. As soon as you enable TLS-RPT, compliant Mail Transfer Agents will begin sending diagnostic reports regarding email delivery issues between communicating servers to the designated email domain. The reports are typically sent once a day, covering and conveying the MTA-STS policies observed by senders, traffic statistics as well as information on failure or issues in email delivery.
• Visibility: It helps you monitor issues with your MTA-STS implementation and email deliverability. TLS-RPT provides enhanced visibility on all your email channels so that you gain better insight on all that is going on in your domain, including messages that are failing to be delivered.
• Enhanced email security: By troubleshooting errors with failed TLS encryption negotiations, you can improve the overall efficacy of your MTA-STS setup, thereby preventing cyber attacks more effectively. Furthermore, it provides in-depth diagnostic reports that enable you to identify and get to the root of the email delivery issue and fix it without any delay.

Easy MTA-STS Deployment with PowerDMARC

MTA-STS requires an HTTPS-enabled web server with a valid certificate, DNS records, and constant maintenance. Implementing MTA-STS can be an arduous task that involves complexities during adoption. From generating policy files and records to maintaining the web server and hosting certificates, it is a long drawn process. PowerDMARC’s DMARC analyzer tool makes your life a whole lot easier by handling all of that for you, completely in the background. Once we help you set it up, you never even have to think about it again.

With the help of PowerDMARC, you can deploy Hosted MTA-STS at your organization without the hassle of handling your public certificates. We help you:

• Publish your DNS CNAME records with just a few clicks
• Make one-click policy updates and optimizations to your record without having to access your DNS settings.
• Verify your policy version and certificate validation
• Detect MTA-STS policy application failures 
• Host your MTA-STS policy text file
• Take the responsibility of maintaining the policy web server and hosting the certificates
• Detect connection failures, connection successes, and connection issues faster with simplified reports
• Ensure RFC compliance and support for the latest TLS standards

PowerDMARC makes the process of implementing SMTP TLS Reporting (TLS-RPT) easy and speedy. We convert the complicated JSON files containing your reports of email delivery issues into simple, readable documents (per result and per sending source) that you can easily understand.
Sign up today to quickly enforce emails to be sent to your domain over a TLS-encrypted connection, and make your connection secure against MITM and other cyber attacks.

“`

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• How to Create and Publish a DMARC Record - March 3, 2025
• How to Fix “No SPF record found” in 2025 - January 21, 2025
• How to Read a DMARC Report - January 19, 2025