MTA-STS and TLS-RPT: forcing encrypted delivery

Mail between servers is encrypted opportunistically: the sending server offers STARTTLS and the receiving server accepts it. If someone on the path removes the STARTTLS offer, or presents any certificate at all, most senders carry on in plain text because that is what "opportunistic" means. MTA-STS (RFC 8461) lets a receiving domain say "always use TLS with a valid certificate for these MX hosts, or do not deliver".

The two parts

1. A DNS TXT record at _mta-sts.example.co.uk containing v=STSv1; id=20260919 where id changes whenever the policy changes.
2. A policy file served over HTTPS at https://mta-sts.example.co.uk/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.co.uk
mx: *.mx.example.net
max_age: 604800

Start with mode: testing, watch the reports for a week or two, then switch to enforce.

The Mail facet fetches the policy, checks the certificate on the mta-sts. host and confirms every MX host you actually publish matches an mx: line. A mismatch in enforce mode means large senders will refuse to deliver.

TLS-RPT

TLS-RPT (RFC 8460) is the reporting half. A TXT record at _smtp._tls.example.co.uk such as v=TLSRPTv1; rua=mailto:tls-reports@example.co.uk asks senders to email you a daily summary of connections that failed the policy. Set it up before enforcing MTA-STS so that a misconfigured MX shows up as a report rather than as lost mail.

Who needs it

Any domain that receives mail worth protecting from interception: businesses, anyone handling password resets or invoices. Gmail, Outlook.com and most large providers honour MTA-STS when sending to you.