Glossary
MTA-STS
SMTP MTA Strict Transport Security lets a domain publish a policy stating that mail sent to it must arrive over an authenticated TLS connection. It exists because SMTP's own opportunistic encryption can be stripped by anything on the network path, silently downgrading a connection to plain text. The policy is published in two places — a short DNS record and a file served over HTTPS — and senders that support it refuse to deliver when the conditions are not met.
The problem it solves
SMTP encryption is opportunistic: a sending server asks whether the receiver supports STARTTLS and encrypts if it does.
An on-path attacker can remove that offer from the conversation, and the sender falls back to plain text without any error, because the fallback is the specified behaviour.
The certificate presented by a mail server is also not validated against the hostname by default in many implementations, so a substituted server is accepted.
MTA-STS closes both: it states that TLS is required and that the certificate must be valid for the MX hostname, so a downgrade becomes a delivery failure rather than a silent change.
How the policy is published
A TXT record at `_mta-sts.example.com` carrying a version and an `id` value. The identifier changes whenever the policy changes, which is how senders know to re-fetch.
A policy file served over HTTPS at `https://mta-sts.example.com/.well-known/mta-sts.txt`, listing the MX hostnames, the mode, and a maximum age.
The HTTPS requirement is the security anchor: the policy is trusted because it was fetched over a validated TLS connection from a name under your control.
That also means the `mta-sts` subdomain needs its own valid certificate, which is the step most often forgotten.
The three modes
`testing` applies no enforcement. Senders report failures through TLS reporting but deliver anyway. This is where every deployment should start.
`enforce` makes senders refuse delivery when TLS cannot be established or the certificate does not match. Mail is deferred rather than lost, but a mistake here delays real mail.
`none` withdraws the policy, and is the documented way to stop using MTA-STS rather than deleting the records.
The `max_age` value caches the policy at senders, so moving from `enforce` back to `none` takes effect only as that cache expires — which argues for a modest value while a deployment is new.
How to check it
`dig _mta-sts.example.com TXT +short` shows whether a policy is advertised.
`curl https://mta-sts.example.com/.well-known/mta-sts.txt` fetches the policy, and any certificate error here means the policy cannot be trusted by anyone.
Confirm the MX hostnames listed in the file match the domain's actual MX records exactly. A stale list is the failure mode that causes deferred mail under `enforce`.
Deploy TLS reporting alongside it, so failures are visible before enforcement is switched on.
Frequently asked questions
- Does MTA-STS encrypt my email?
- It requires the connection carrying it to be encrypted and authenticated. It is not end-to-end encryption and the message is readable at each server.
- Can MTA-STS cause mail to be lost?
- Under enforce, a failure defers delivery rather than discarding it. Senders retry, so a short misconfiguration delays mail rather than losing it.
- Why does it need an HTTPS server?
- The policy is trusted because it was fetched over a validated TLS connection from a subdomain you control, which DNS alone cannot provide without DNSSEC.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website