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.
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!
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. If you email 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. Furthermore, MTAs store MTA-STS policy files, making it more difficult for attackers to launch a DNS spoofing attack.
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.
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
| Fields | Description | Example |
| version | The version of the MTA-STS policy format | STS1 |
| mode | The policy enforcement level among 3 available options: none, testing, and enforce | testing |
| mx | A list of the domain’s valid Mail Exchange (MX) servers | mail.domain.com |
| max-age | The duration in seconds for which the policy should be cached by external mail servers | 86400 |
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:
- A Registered Domain Name
- 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
- A DNS TXT record for MTA-STS
- HTTPS web server
- Mail server configured to use TLS
- Mail server hostname matching the entries in the mx field of your policy file
- 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:
- None: This policy nullifies your MTA-STS configuration as external servers will consider the protocol inactive for the domain
- 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
- 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 and a lack of support for secure protocols.
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.
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.
- Visibility: It helps you monitor issues with your MTA-STS implementation and email deliverability.
- 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.
Easy MTA-STS Deployment with PowerDMARC
MTA-STS requires an HTTPS-enabled web server with a valid certificate, DNS records, and constant maintenance. 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:
- 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
- Detect connection failures, connection successes, and connection issues faster with simplified reports
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.
- Email Phishing and DMARC Statistics - November 22, 2024
- DMARC Compliance and Requirements for 2025 - November 21, 2024
- What Is DMARC Policy? None, Quarantine And Reject - September 15, 2024