Guides MTA-STS
What is MTA-STS?
After discovering an enforce policy, MTA-STS lets supporting senders deliver only securely to the right mail server. TLS-RPT can report TLS problems.
Mail servers normally try to use TLS, but may fall back to an unencrypted connection when something fails. With MTA-STS you publish which mail servers are valid. Supporting senders that successfully discover and cache an enforce policy then refuse unsafe delivery.
How it works
MTA-STS has two parts:
- a small TXT record at
_mta-sts.<domain>saying you have a policy - a policy file published over HTTPS at
https://mta-sts.<domain>/.well-known/mta-sts.txt
The file lists valid mail servers (MX) and a mode: enforce requires secure delivery, testing reports without blocking delivery, and none withdraws the policy in a controlled way. Only a discovered policy in enforce makes a supporting sender refuse delivery when TLS or server identity fails.
TLS-RPT: the reports
TLS-RPT (TLS Reporting) is the reporting channel next to MTA-STS. You publish a TXT record at _smtp._tls.<domain> with an address. Supporting reporting senders can send periodic aggregate reports about successful and failed TLS delivery; daily reporting is recommended, not guaranteed.
Example: _smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls@example.com". That can expose problems before you set MTA-STS to enforce.
Why you'd want this
An attacker between two mail servers can try to disrupt initial MTA-STS discovery or the TLS connection. Once a supporting sender has discovered and cached a valid enforce policy, that policy helps prevent downgrade and redirection to another MX. Initial discovery itself is not guaranteed.
MTA-STS protects incoming mail transport. It is separate from SPF, DKIM and DMARC, which cover sender authentication.
Watch out when setting it up
MTA-STS asks a bit more than just a DNS record: you also need a working HTTPS page on mta-sts.<domain> with a valid certificate. So always start in testing mode and turn on TLS-RPT, collecting reports for a few weeks. Only once everything is fine do you switch to enforce. Set it strict too soon while something's off, and incoming mail can be delayed or refused.
One more pitfall: senders remember your policy for quite a while. If you change it later (say, new mail servers), also change the id= in the TXT record. Otherwise senders keep using your old, cached policy.
Primary sources
Frequently asked questions
What's the difference with DANE/TLSA?
Both secure mail transport, but differently: MTA-STS leans on HTTPS and certificates and works without DNSSEC. DANE/TLSA pins the certificate in DNS and requires DNSSEC. Large providers often choose MTA-STS.
Do I need a separate web server?
You need an HTTPS-reachable subdomain mta-sts.<domain> that serves the policy file. Many hosts and services offer ready-made support for this.
Does MTA-STS work for outgoing mail?
No, it protects your incoming mail: it tells others how to deliver to you safely. For your outgoing mail you depend on the recipient's MTA-STS policy.
What exactly does TLS-RPT do?
Supporting implementations can send aggregate reports about TLS delivery and failures. That can expose problems before you set MTA-STS to enforce.