What is MTA-STS?
MTA-STS is an inbound mail protocol designed to add a layer of encryption/security between sending and receiving mail servers. It was designed to patch an existing hole in the STARTTLS protocol that allowed for communication to be unencrypted via an attacker who could remove parts of the SMTP session (such as the “250 STARTTLS” response). This is accomplished by bringing DNS as a third party to verify connections.
MTA-STS is short for SMTP MTA-STS, which is short for Simple Mail Transfer Protocol (SMTP) Mail Transfer Agent (MTA) Strict Transport Security (STS). The purpose of MTA-STS is to encrypt and secure communications between SMTP servers via TLS (Transport Layer Security) preventing man-in-the-middle attackers from viewing and manipulating in-transit emails.
The MTA-STS protocol works by having a DNS record that tells mail servers to fetch a policy file via HTTPS from a defined subdomain. This file contains a list of the receiver’s mail servers which are authenticated and approved to receive the messages and also what policy to apply to inbound messages.
What are the requirements for MTA-STS?
Ensure you have verified the following prior to deploying MTA-STS.
- Your MX supports SMTP over TLS version 1.2 or later.
- Your server supports SSL (HTTPS)
- Your MX uses a TLS certificate issued by a root certificate authority that is not expired, and matches its domain name.
When implementing MTA-STS, which requires DNS entries, you should also enable TLS Reporting, which also requires its own DNS entries. By implementing TLS reporting, you will be able to see the performance of your domains and the success/failure rate of your MTA-STS policies. This will give you important insight into which mail senders you need to work with to ensure no interruption in mail flow.
What is the MTA-STS Policy File?
The MTA-STS Policy File file is a plain-text file containing a set of the following key/value pairs:
version: The protocol version of the file. At the time of this writing, it must be STSv1.
mode: This is the policy mode. The values available are testing, enforce, or none.
- testing: Senders will send your reports (TLSRPT) indicating policy application failures. This requires TLSRPT to also be implemented to work. TLS connection failures will not be blocked, while being able to receive reports.
- enforce: Sending mail servers that support MTA STS will not deliver mail to your domain where the certificate authentication fails, or cannot negotiate TLS. Reports on these failures are sent as well.
- none: Senders will treat the domain as thought it does not have any active policy. It effectively disables MTA STS.
mx: The MX records for the domain. It has to match the MX records published in your domain’s DNS. You can specify either the FQDN or a wildcard host (mx: mail.example.org or mx: *.example.org). Ensure each MX records are added on their own line in the policy file.
max_age: The maximum lifetime of the policy expressed in seconds. This represents the length of time a sender would cache the domain’s policy. It is recommended to use a value equivalent of several weeks or greater, but not exceeding 31557600 (roughly 1 year).
Example of policy file:
How to implement MTA-STS
Once the policy text file is ready, it must be published on the web to be accessed by senders.
The file must be available at a specific URL on a subdomain of your domain. An example of URL would be:
The above requires creating the subdomain mta-sts, along with a directory named .well-known in the subdomain. Then upload the policy text file to the .well-known directory of the subdomain.
How to publish the DNS record
A DNS TXT resource record is needed in order to enable MTA-STS on your domain. This record exists at a unique subdomain:
For the example.org domain, it would be _mta-sts.example.org.
The TXT record contains 2 key/value pairs.
- “v” The version of the protocol, which currently only supports the value STSv1.
- “id” A string of 1 to 32 alphanumeric characters meant to track policy updates. This string must be updated every time there is a change made to your MTA-STS policy file. A good practice is to use the date and time of the change to make up the ID number.
An example of such record is as below:
_mta-sts.example.org. IN TXT “v=STSv1; id=202104012135;”
Log into your dmarcian account to use our MTS-STS Inspector Tool, below, to look at the records for your own domains.
We’re Here to Help
With a team of email security experts and a mission of making email and the internet more trustworthy through domain security, dmarcian is here to help assess an organization’s domain catalog and implement and manage DMARC for the long haul.
Want to continue the conversation? Head over to the dmarcian Forum.