Dr.Who
← blog

Do you need MTA-STS and TLS-RPT?

· mta-sts · tls-rpt · email · smtp · tls

mta-ststls-rptemailsmtptls

MTA-STS and TLS-RPT protect the transport between mail servers: they force SMTP to use TLS and let you detect when it gets downgraded or intercepted. That is a different job from SPF, DKIM, and DMARC, which stop someone from spoofing your From: address. If you have already taken DMARC to enforcement and you handle email an attacker would want to read, these two records close a real interception gap. Most small senders can defer them — but they are cheap to add.

What problem they actually solve

SMTP delivery uses opportunistic TLS by default. The sending server asks "do you support STARTTLS?" and if so, encrypts. The catch: a man-in-the-middle can strip the STARTTLS advertisement, or present a bogus certificate, and the sender quietly falls back to plaintext rather than failing the delivery. That is a TLS downgrade attack, and opportunistic TLS has no defence against it.

MTA-STS fixes the downgrade. It lets your domain declare that senders must use TLS with a valid certificate matching your MX hosts — and refuse delivery if they can't. TLS-RPT is the feedback channel: receiving providers send daily reports of any TLS negotiation failures, so you learn when delivery is being tampered with instead of guessing.

This is orthogonal to spoofing. SPF/DKIM/DMARC answer "is this mail really from you?" MTA-STS/TLS-RPT answer "is the pipe carrying your mail encrypted and unmolested?" You want both.

How MTA-STS is published

Two parts. First, a TXT record at _mta-sts.yourdomain.com:

v=STSv1; id=20260621000000

The id is a version string you bump whenever the policy changes — senders cache the policy and re-fetch when the id moves.

Second, a policy file served over HTTPS at a fixed path:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

That file lists your MX hosts and the enforcement mode:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.mailprovider.example
max_age: 604800

mode is none, testing, or enforce. The mta-sts host needs its own valid TLS certificate — if the file isn't reachable over HTTPS, senders ignore the whole policy.

How TLS-RPT is published

One TXT record at _smtp._tls.yourdomain.com:

v=TLSRPTv1; rua=mailto:[email protected]

rua can also be an https: endpoint. Reports arrive as JSON, roughly daily, summarising successful and failed TLS sessions per source. Turn this on before you enforce anything — it is your only window into whether enforcement will break delivery.

Roll it out in the right order

Priority matters. Get SPF, DKIM, and DMARC to p=reject first; those stop the attacks most senders actually face. Transport security comes after.

Then for MTA-STS: publish TLS-RPT, publish the policy in mode: testing, and watch the reports for a couple of weeks. Testing mode tells senders to report failures but still deliver, so you catch a stale MX entry or a bad cert without bouncing real mail. Once the reports are clean, flip mode to enforce and bump the id.

Check your MTA-STS and TLS-RPT setup →

Further reading