Between mail servers, encryption is negotiated with STARTTLS: the receiving server announces that it supports it and the sending server, if it wishes, turns it on. The problem is that this negotiation happens in clear text and, if something goes wrong, most servers prefer to deliver the message unencrypted rather than not deliver it at all. Anyone sitting in the middle of the connection can strip the STARTTLS announcement and force the servers to talk in clear. MTA-STS exists to close this gap, and TLS-RPT to tell you when encryption fails.
What MTA-STS does
MTA-STS lets a domain owner publicly declare two things:
- its inbound mail servers support TLS with valid certificates;
- senders must not deliver messages to that domain if an encrypted connection cannot be established.
Sending servers that support the standard download the policy, cache it for the stated period and apply it to subsequent deliveries. The protection therefore covers inbound mail to your domain, not the mail you send.
The key point is that the policy is fetched over HTTPS, a channel authenticated by a web certificate, and not just from DNS, which without DNSSEC can be spoofed.
The three pieces to publish
The DNS record
A TXT record at _mta-sts announces that a policy exists and gives its version:
_mta-sts.example.com. TXT "v=STSv1; id=20261027T1200"
The id value is an arbitrary identifier that must change every time you modify the policy: it is the signal that tells senders to download it again.
The policy file
The policy is a text file served over HTTPS on a dedicated subdomain, mta-sts, at the path /.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400
The mx lines list the permitted mail servers, and a wildcard can be used for a whole subdomain. The max_age value states for how many seconds the policy remains valid in senders' caches.
The certificate
The mta-sts subdomain needs a valid HTTPS certificate. Each MX server must also present, on port 25, a certificate valid for its own name. This is the most frequently overlooked requirement: many mail servers still use self-signed certificates or ones with a different name, and with MTA-STS in enforce mode mail to them would be blocked.
The modes
| Mode | Effect |
|---|---|
none |
the policy is not applied; used to withdraw it in an orderly way |
testing |
senders deliver anyway, but report problems via TLS-RPT |
enforce |
senders don't deliver if TLS is invalid or the server isn't listed |
The right path is the same as with DMARC: start with testing, read the reports for a few weeks, fix the problems and only then move to enforce, raising max_age to longer values, say one or two weeks.
TLS-RPT: failure reports
TLS-RPT is a separate standard, but it should be set up alongside. You publish a TXT record at _smtp._tls with the address that will receive reports:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-report@example.com"
Senders that support it send daily reports in JSON, with the number of successful and failed sessions and the type of error: expired certificate, name mismatch, server not in the policy, policy could not be fetched.
Even without MTA-STS, TLS-RPT is useful: it shows whether some senders fail to establish encrypted connections with your servers.
Common mistakes
- Forgetting to update
idafter a change: senders keep using the old policy. - Adding a new MX server without listing it in the policy: in enforce mode, mail to that server is refused.
- Letting the certificate of the
mta-stssubdomain or of the MX servers expire. - Moving to enforce without ever having read a report.
- Using very long
max_agevalues while still testing, which makes every change of mind slow.
If you use a hosted mail service, check that its MX servers have valid certificates for the names listed: they usually do, but the confirmation should come from the provider's documentation.
In short
- STARTTLS alone can be bypassed; MTA-STS declares that encryption is mandatory.
- The policy is published with a TXT record and a file served over HTTPS on a dedicated subdomain.
- MX servers must present certificates valid for their own names.
- Start in testing with TLS-RPT active and move to enforce after reading the reports.
- Every policy change needs a new
idvalue.
