Setting up MTA-STS and TLS-RPT: enforce encrypted email delivery

7 min read · updated 11 Oct 2026 · Timo Kessel

Emails between servers are usually transmitted encrypted – but only “if possible”. An attacker on the network can suppress encryption, and the sending server won't notice. MTA-STS closes this gap: your domain declares that emails to it may only be delivered encrypted and only to the right servers.

The problem: STARTTLS is optional

When a mail server delivers an email to your domain, it asks via STARTTLS whether encryption is possible. If your server doesn't offer it – or an attacker removes the offer on the way – the email is simply transmitted unencrypted. Certificates are usually not strictly checked either.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) reverses this. Large providers such as Gmail and Microsoft follow it: they only deliver to your domain encrypted and only to servers whose certificate is valid and whose name is in your policy.

The three parts of MTA-STS

Part	Where	Purpose
TXT record	`_mta-sts.example.com`	Announces that there's a policy and states its version (`id`)
Policy	`https://mta-sts.example.com/.well-known/mta-sts.txt`	Defines the mode, allowed MX servers and validity
TLS-RPT (optional, recommended)	`_smtp._tls.example.com`	Address for daily reports on encryption failures

Step-by-step setup

Check that your MX servers encrypt properly. Every server in your MX records needs STARTTLS and a valid certificate issued for its name (not for some other name of the host). Postwacht's domain monitoring shows this for every MX server.
Create the policy. It's a simple text file that must be reachable via HTTPS on the subdomain mta-sts – with a valid certificate for mta-sts.example.com:
```
version: STSv1
mode: testing
mx: mail.example.com
mx: *.mailserver.example
max_age: 86400
```
Every MX server must match an mx line. An asterisk stands for exactly one label: *.mailserver.example matches mx1.mailserver.example, not a.b.mailserver.example.
Create the TXT record:
```
_mta-sts.example.com.  TXT  "v=STSv1; id=20261011T120000"
```
The id can be anything, but it must change with every change to the policy. A timestamp is practical.
Start with mode: testing. In testing mode nothing is rejected; failures only appear in the TLS-RPT reports. After two to four weeks without problems, switch to mode: enforce, increase max_age to a week or more (e.g. 604800) and change the id.

TLS-RPT: reports on failures

With TLS-RPT (RFC 8460) you receive daily reports – similar to DMARC – on whether delivery to your domain worked encrypted:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Especially in testing mode, these reports are the only way to see whether switching to enforce would cost you emails.

Common mistakes

Mistake	Consequence
Policy not reachable or certificate of `mta-sts.` invalid	The policy is ignored – no protection
New MX server, but not in the policy	In `enforce` mode, emails to this server are not delivered
Policy changed, `id` not	Senders keep using the old version for up to `max_age`
Certificate on the MX server expired	In `enforce` mode, no more emails arrive
Redirect from `mta-sts.` to another address	Redirects are not allowed; the policy counts as not retrievable

Because an expired certificate with enforce immediately costs you emails, monitoring is worth it. In domain monitoring, Postwacht checks the policy every day, whether all MX servers are listed in it and how long the certificates remain valid – and notifies you in good time before they expire.