tmailrDeliverability
MTA-STS and TLS-RPT, and when they are worth it
25 July 2026 · 2 min read · TMailr
Mail between servers is usually encrypted, and until fairly recently that encryption was worth less than it sounded, because it was optional in a way an attacker could exploit.
The problem: STARTTLS is a suggestion
A sending server connects, the receiver advertises STARTTLS, and they upgrade. Anybody able to modify traffic in between can simply remove that advertisement, and a well-behaved sender falls back to plain text. The message goes out unencrypted and neither end notices.
Certificates have the same weakness. Most senders do not verify the receiver’s certificate, because refusing mail from a badly configured server was historically worse than accepting it insecurely. So a wrong certificate is not an obstacle either.
MTA-STS: a policy that says do not fall back
You publish a policy stating that mail to your domain must be over TLS, with a valid certificate matching a hostname you list. Senders that support MTA-STS fetch it over HTTPS, cache it, and refuse to deliver over an unencrypted connection from then on.
It takes three pieces: a DNS record announcing the policy, the policy file served over HTTPS at a fixed path, and MX hosts whose certificates actually match.
_mta-sts.example.com TXT "v=STSv1; id=20260801000000" https://mta-sts.example.com/.well-known/mta-sts.txt version: STSv1 mode: enforce mx: mx1.example.com max_age: 604800
Start at mode: testing. It reports violations without refusing anything, so you find out that one of your MX hosts has a certificate for the wrong name before that mistake starts rejecting real mail.
TLS-RPT: find out what happened
MTA-STS without reporting is a policy you cannot audit. TLS-RPT is one DNS record that asks senders to send you daily summaries of their TLS connections to you, successful and failed.
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
The reports are the useful half. They tell you when a certificate expired on one MX, when a sender could not fetch your policy, and whether anything is being downgraded. Publish it first, before the policy, and you have a baseline to compare against.
The order that avoids trouble
- Publish TLS-RPT and read a week of reports.
- Check every MX host serves a certificate valid for the name in its MX record, not just for your website.
- Publish MTA-STS in testing mode, and wait until the reports are clean.
- Switch to enforce, and remember the id changes whenever the policy does.
- Set a reminder for the certificates. In enforce mode an expired certificate stops mail rather than warning about it.
That last point is the whole trade. Enforcement means a configuration mistake becomes undelivered mail, which is exactly what you asked for, and the reason to arrive there through testing mode with reports in hand rather than in one step.
More on deliverability
