Concept

TLS-RPT vs MTA-STS: what each does and why you publish both

MTA-STS enforces TLS on inbound mail to your domain. TLS-RPT tells you when TLS fails. They solve different halves of the same problem and you publish both, but the deployment order matters.

TL;DR

  • 1 MTA-STS = policy. Says 'reject inbound mail not delivered over TLS'.
  • 2 TLS-RPT = telemetry. Tells you daily which senders' TLS attempts failed and why.
  • 3 Always publish TLS-RPT in 'mode=testing' alongside MTA-STS so you see what enforcement WOULD have blocked.
MTA-STS & TLS-RPT: enforcement vs. reporting
MTA-STS Enforcement • Tells senders: TLS is required • Pins MX hostnames to a policy file • Stops downgrade + MITM attacks • Hosted at /.well-known/mta-sts.txt mode: enforce TLS-RPT Reporting • Asks senders: tell us if TLS failed • Daily JSON aggregate reports • Surfaces MITM, cert issues, expired • Published at _smtp._tls.<domain> rua=mailto:tlsrpt@…

MTA-STS enforces TLS; TLS-RPT tells you when senders couldn't honor it. Deploy both. MTA-STS without TLS-RPT is enforcement with no visibility.

What it does

MTA-STS is a policy mechanism: you publish a policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt declaring which MX hosts are authorised and that TLS is mandatory. Sending servers fetch this once per day (per policy cache) and refuse to deliver to your MX if TLS fails. The fundamental problem MTA-STS solves: an attacker who can MITM the SMTP connection downgrades TLS to plaintext, then reads the mail.

TLS-RPT is a feedback mechanism: you publish a TXT record at _smtp._tls.yourdomain declaring an email or HTTPS endpoint to receive daily aggregate reports. Sending servers report TLS handshake failures, certificate problems, and policy-fetch errors. You see exactly which senders' attempts failed and why.

How it works

  1. 1

    Publish TLS-RPT FIRST with rua=mailto:tls@yourdomain. Run it for two weeks. See if anyone's attempts are failing.

  2. 2

    Publish MTA-STS in mode=testing. Senders fetch the policy but DON'T enforce yet — they only report what WOULD have been blocked.

  3. 3

    Watch TLS-RPT reports for two more weeks. If you see policy-fetch failures, fix them (HTTPS on mta-sts.yourdomain, correct policy file, proper cert).

  4. 4

    Switch MTA-STS to mode=enforce. Senders now refuse non-TLS or non-matching-MX delivery.

  5. 5

    Keep TLS-RPT running indefinitely as ongoing monitoring.

Example record

_smtp._tls.yourdomain.com TXT Click to select
v=TLSRPTv1; rua=mailto:tls@yourdomain.com

Common pitfalls

  • Publishing MTA-STS in enforce mode before testing. If your policy file 404s or your MX list is wrong, you bounce real inbound mail immediately.

  • Forgetting to update the policy when you add an MX. The policy file is a static list — if you add a new MX server, you have to update the file too.

  • TLS-RPT rua with a mailbox you don't read. Reports surface real outages but only if someone notices.

  • max_age too short in the policy file. Senders cache the policy; a max_age of 600 means every sender re-fetches every 10 minutes — wasteful and noisy.