Three years ago we wrote about implementing SPF, DKIM and DMARC for email security. This short blog details another email security protection - MTA-STS.
Overview
SPF, DKIM and DMARC all affect the reliability of emails you send and receive, and can help to prevent spam and phishing. MTA-STS is a little different, as it helps control the communication between email servers. Specifically, the enforcement of TLS encryption. As per the relevant internet standard RFC:
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
So MTA-STS means we demand the same encryption between email servers as we now expect for all web browsing and application traffic. Which sounds sensible to me. So, how do we apply it to our own domain?
MTA-STS Requirements
If you’ve already configured your SPF, DKIM and DMARC records, you’ll know such configuration is quite fiddly. And getting it wrong means emails can get lost. You’ll therefore be delighted to learn that MTA-STS is also a little fiddly to put in place. But once in place it shouldn’t need much, if any, maintenance.
MTA-STS needs at least two things in place to work; three if you want reports on success/failures. You need a DNS record and a published policy page, plus optionally a second DNS record. They are all detailed below.
Policy DNS TXT Discovery Record
This record is a requirement, and enables a simple domain (DNS) lookup to find out whether a given domain implements MTA-STS. That allows someone else’s email server can check if yours supports and mandates MTA-STS.
It’s a DNS TXT record that you can publish via your domain registrar. It has the prefix _mta-sts. before the domain, e.g. _mta-sts.hexiosec.com for our own record. If you’re on the command line you can use dig to fetch a record::
$ dig +short TXT _mta-sts.hexiosec.com
"v=STSv1; id=002c1714;"
This record just specifies two things. Firstly, a a version string (which must be STSv1), and must be the first field in the record.
Secondly, a unique ID for the policy file (this is next). This ID field allows senders to track if the policy has changed and needs to be fetched again. It should change if the policy changes. The UK NCSC recommends using a timestamp for it, from when you publish a new policy file.
Online Policy File
If the DNS TXT record is in place, senders should then fetch the policy file to get your MTA-STS config. This must be hosted on HTTPS, and should be served from a .well-known location on your website, specifically:
https://mta-sts.<domain>/.well-known/mta-sts.txt
The policy file specifies:
- The version in use (there’s only one,
STSv1). - The mode in use (effectively one of “off”, “testing”, or “on”. AKA
none,testingorenforce, respectively). - The allowed mail servers for your domain, i.e. your MX mail records.
- A lifetime for the policy - somewhere between a day and a year is sensible.
For example, our own record looks like this:
version: STSv1
mode: enforcing
mx: hexiosec-com.mail.protection.outlook.com
max_age: 604800
This specifies we’re enforcing MTA-STS, we expect email to come only from Microsoft 365 (aka mail.protection.outlook.com), and the policy lasts for 604800 seconds (7 days).
You can initially have a policy in testing mode, to check your configuration is working. Once deployed and working, all policies should be in enforcing mode.
With those two things in place you have MTA-STS configured. Almost. There is also an optional third record you can use to get reporting on how its working. That’s especially useful if you publish a new record in testing mode - you can monitor the reporting for a while to check there are no issues, and then update the record to enforcing instead.
Reporting DNS TXT Record
This is another DNS TXT record, which only serves to publish an email address to which other servers can report on MTA-STS usage. It has the name prefix _smtp._tls, before the domain.
E.g. our own record, which again we can fetch on the command line with dig:
$ dig +short TXT _smtp._tls.hexiosec.com
"v=TLSRPTv1;rua=mailto:[email protected]"
As you can see, this simple record just defines the fixed version TLSRPTv1 and specifies our reporting address, similar to the DMARC reporting mechanism.
For reference, when in testing mode the received reports look like the below. The key fields are the summary counts of success or failure:
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2025-10-12T00:00:00Z",
"end-datetime": "2025-10-12T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "2025-10-12T00:00:00Z_hexiosec.com",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"mx: hexiosec-com.mail.protection.outlook.com",
"max_age: 604800"
],
"policy-domain": "hexiosec.com",
"mx-host": [
"hexiosec-com.mail.protection.outlook.com"
]
},
"summary": {
"total-successful-session-count": 2,
"total-failure-session-count": 0
}
}
]
}
These reports are easily aggregated and parsed out - as long as you’re getting successful sessions then everything is fine with your configuration.
Related Posts
