MTA-STS: requiring TLS for mail delivered to your domain

The problem

SMTP uses opportunistic STARTTLS: if the encryption offer is stripped by an attacker on the path, or the certificate is invalid, most senders fall back to plaintext delivery. MTA-STS lets a receiving domain declare that its MX hosts support TLS with valid certificates, so compliant senders refuse to deliver otherwise.

Two parts: DNS and HTTPS

A TXT record at _mta-sts.domain announces the policy and an id that changes whenever the policy changes. The policy itself is a text file served over HTTPS at https://mta-sts.domain/.well-known/mta-sts.txt with a valid certificate. It lists mode, allowed MX patterns, and max_age in seconds.

_mta-sts.example.org.  TXT  "v=STSv1; id=20261102T1000"

# https://mta-sts.example.org/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mx1.example.org
mx: *.mail.provider.example
max_age: 86400

Lab: publish in testing mode and verify

For a domain you manage, list its MX hosts and confirm each presents a valid certificate for its name. Publish the policy file in testing mode and the TXT record, then fetch both to verify. Pair it with TLS-RPT so you receive failure reports before switching to enforce and raising max_age to a week or more.

dig +short MX example.org
openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org </dev/null 2>/dev/null | openssl x509 -noout -subject -enddate
dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txt

Modes and changes

testing reports failures but still delivers; enforce refuses delivery when TLS or certificate checks fail; none withdraws the policy. When MX hosts change, update the policy file first, then change the id in DNS so senders refetch it. Remember senders cache the policy for max_age.

• testing: report only
• enforce: refuse insecure delivery
• none: withdraw
• Change id whenever the file changes