MTA-STS and TLS-RPT: what they do and whether you need them
MTA-STS is a policy with which you tell sending servers that mail to your domain may only be delivered over an encrypted and verified TLS connection. TLS-RPT is the reporting channel that goes with it: senders send you a daily report of connections that did not comply with that policy. Both protect the mail you receive; for the mail you send, what you mainly need is a sending server that respects these policies at the recipient.
The problem they solve
Mail between servers has largely travelled encrypted for years, via STARTTLS. But STARTTLS is opportunistic: the sending server asks whether the recipient supports encryption, and if the answer does not come or the certificate is wrong, it silently falls back to an unencrypted connection. Someone sitting between the two servers can filter out that question and let the mail pass in readable form. MTA-STS removes that fallback option: if your policy is set to "enforce", a sender that cannot establish encryption may not deliver the mail.
How MTA-STS works
It consists of two parts that you publish yourself:
- A DNS record at _mta-sts.yourdomain.be with a version and an id. You change the id every time you adjust the policy; senders then know they need to fetch it again.
- A policy file at https://mta-sts.yourdomain.be/.well-known/mta-sts.txt. It contains the mode (none, testing or enforce), the mail servers allowed to receive for your domain, and how long a sender may remember the policy.
That second part explains why MTA-STS goes over HTTPS and not only DNS: the certificate of that web page proves the policy really comes from your domain, without DNSSEC being required. The alternative, DANE, does the same via DNS but does require DNSSEC on your domain, which in practice is not enabled by default at many Belgian registrars and hosting packages.
How TLS-RPT works
TLS-RPT is a single DNS record at _smtp._tls.yourdomain.be with an address at which you want to receive reports. Senders that support it (including the large providers) then send you a report once a day with, per sending server, how many connections succeeded and how many failed, and why: certificate expired, server name does not match, STARTTLS not offered, policy could not be fetched.
That report is the reason to start with TLS-RPT even before you enforce MTA-STS. It tells you whether there are senders who will no longer be able to deliver your mail once you set the mode to enforce. Compare it with DMARC: observe first, then tighten. Our article on reading a DMARC report explains the approach; the logic is the same.
Do you need it?
That depends on which side of the connection you are looking at.
As a recipient
If your domain receives sensitive mail (personnel files, medical data, legal correspondence, payment instructions), MTA-STS is a cheap protection against mail being intercepted in transit. For a domain that mostly receives newsletters and order confirmations the gain is smaller, but it costs little: a DNS record, a small static file on a subdomain with a valid certificate, and a mailbox for the reports.
As a sender
MTA-STS on your own domain changes nothing about the mail you send. What does count: the server you send with must check and respect the MTA-STS policy of the recipient, and must itself have a correct TLS certificate. If you send through an SMTP relay, that is the relay's responsibility. Ask if you are not sure: a sender that ignores the policy is refused at a recipient in enforce mode, and you then see that as a bounce.
A practical step-by-step plan
- Set the TLS-RPT record and let the reports come in for a few weeks at an address someone actually reads.
- Publish the MTA-STS policy in testing mode. Senders then report deviations in the reports but still deliver normally.
- Fix what you see in the reports: usually a mail server that was not in the policy, or a certificate issued for a different name.
- Set the mode to enforce and increase the id in the DNS record.
- Look at the reports monthly and check, with every change to your mail servers, whether the policy file is still correct.
Whoever uses a hosted mail platform finds the server names for the policy in that platform's MX settings. Whoever manages their own mail servers must watch the certificate of those servers: an expired certificate in enforce mode means external mail stops arriving.
What it does not do
MTA-STS says nothing about who may send mail on your behalf; for that, SPF, DKIM and DMARC remain necessary. Nor does it protect the path from the receiving server to the reader's mailbox, and it does not encrypt the content on the server itself. It closes one specific gap: the unencrypted fallback between two mail servers.
Frequently asked questions
Is MTA-STS mandatory?
No. It is a recommendation supported by the large providers, not a condition for delivery. In some sectors and tenders it is increasingly requested, though.
Can I set MTA-STS if my mail is hosted at Microsoft 365 or Google Workspace?
Yes. You publish the policy yourself, with that platform's MX servers in it. Both platforms have valid certificates on those servers.
What if I only send and receive nothing on that domain?
Then MTA-STS makes little sense for that domain. Spend your time on authentication and deliverability instead; that is what your outgoing mail is judged on.