Guides MTA-STS
What is MTA-STS?
Normally mail servers try to reach each other encrypted (over TLS), but if that fails they often silently fall back to an unencrypted connection, and an attacker can even force that. MTA-STS closes that gap: you publish a policy saying 'deliver my mail only encrypted, and only to these servers'. Sending servers that support MTA-STS honor it and 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 you publish over HTTPS at
https://mta-sts.<domain>/.well-known/mta-sts.txt
That policy file lists which mail servers (MX) are valid and which mode you're in: enforce (truly enforce), testing (only report, don't refuse yet) or none. A sending server fetches the policy, remembers it for a while, and from then on only delivers encrypted. If that fails once, it holds the mail or sends it back. Delivering unencrypted is no longer allowed.
TLS-RPT: the reports
TLS-RPT (TLS Reporting) is the reporting channel next to MTA-STS: it tells you whether the enforcement is actually working out. You publish a TXT record at _smtp._tls.<domain> with an address, and the parties that send you mail give you a daily report: how much mail could be delivered encrypted and where it failed.
Example: _smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls@example.com". That way you spot problems before you set MTA-STS to enforce.
Why you'd want this
Without MTA-STS, an attacker sitting between two mail servers can 'push away' the encryption (a downgrade attack) and read or redirect the mail. MTA-STS makes that impossible for servers that support it, and the big providers (Google, Microsoft) do.
It specifically protects the transport of incoming mail. It's separate from SPF/DKIM/DMARC (which are about sender authenticity). MTA-STS is about a secure connection.
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.
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?
It gives you daily reports on whether mail could be delivered encrypted and where it failed. That way you see problems before you make MTA-STS strict.