MTA-STS and TLS-RPT: the email-in-transit protection you probably skipped

If you've set up SPF and DMARC, you've handled who's allowed to send as your domain. But there's a separate problem they don't touch: how mail gets delivered to you, and whether it's encrypted on the way. That's where MTA-STS and TLS-RPT come in, and almost nobody publishes them.

Here's the gap. When another mail server delivers to you, it connects to your MX host and tries STARTTLS to encrypt the session. The catch is that classic SMTP treats encryption as optional - if the STARTTLS step fails or is stripped, the sending server quietly falls back to plaintext rather than refusing. A network attacker in the path can force exactly that: strip the STARTTLS advertisement and your inbound mail flows in the clear, readable and modifiable. MTA-STS is the policy that says "no - require TLS, and if you can't get it, don't deliver."

How the two records work together

MTA-STS has two parts that both have to be present. A TXT record at _mta-sts.<domain> advertises that a policy exists, and an HTTPS-served file at https://mta-sts.<domain>/.well-known/mta-sts.txt spells it out. The policy's mode field is the part that matters:

• mode: none - published but inert. No protection.
• mode: testing - report problems but still deliver over plaintext. A staging step, not a destination.
• mode: enforce - require TLS; refuse to deliver if it can't be established. This is the one that actually stops a downgrade.

TLS-RPT is the companion record: a TXT at _smtp._tls.<domain> with v=TLSRPTv1 that asks sending servers to email you reports when a TLS delivery fails. Without it, a downgrade attack or a broken cert on your MX is invisible - mail just silently degrades and you never know. With it, you get told.

Publish the policy and turn on reporting

This is all DNS plus one static file. No code, no app change.

# no _mta-sts record, no policy file, no TLS-RPT
# inbound mail: STARTTLS optional, downgrade possible, failures invisible

Publish the _mta-sts TXT record and the policy file, start in mode: testing to confirm your MX and certificate are healthy, then move to mode: enforce once the TLS-RPT reports come back clean. Add the _smtp._tls record at the same time so you have visibility from day one. These are lower-severity than a leaked key or an open admin panel - they're hardening, not an open wound - but they close a real downgrade path that SPF and DMARC leave wide open.

Whether you publish these is a pair of public DNS records and a public HTTPS file, which means we check them the same way any sending server would. SurfaceCheckr only raises them for domains that actually receive mail (there's an MX record), then reads the _mta-sts TXT and policy file and the _smtp._tls record, and notes when they're missing or stuck below enforce. It reads what's published and stops there. That's the check that tells you whether your inbound mail can still be quietly pulled down to plaintext.