MTA-STS Explained: Enforcing Encrypted Mail Delivery

The Problem: STARTTLS Is Only Opportunistic

SMTP normally negotiates encryption with STARTTLS – the sending server offers to upgrade to TLS, and if the receiving server supports it, the connection gets encrypted. The catch is that this is opportunistic, not mandatory. An attacker positioned in the middle of the connection can simply strip the STARTTLS offer out of the conversation, and both ends will happily fall back to sending the message in plaintext, with neither side any the wiser.

MTA-STS (Mail Transfer Agent Strict Transport Security) closes this gap by letting a domain publish a policy saying, in effect: “mail to this domain must always use TLS, from a server matching this certificate, or don’t deliver it at all.”

Two Parts: a DNS Record and a Policy File

MTA-STS needs both a DNS TXT record and a policy document hosted over HTTPS.

1. The DNS record, which just points to a policy version and tells sending servers a policy exists:

_mta-sts.example.com. TXT "v=STSv1; id=2026072601"

The id is just a version string – change it any time the policy file changes, so sending servers know to re-fetch it rather than relying on a cached copy.

2. The policy file, hosted at a fixed, well-known HTTPS location:

https://mta-sts.example.com/.well-known/mta-sts.txt

With contents like:

version: STSv1
mode: enforce
mx: mail.example.com
mx: mail2.example.com
max_age: 604800

• mode – enforce rejects delivery on TLS failure; testing reports failures without blocking mail, useful while rolling this out; none disables enforcement.
• mx – the mail servers permitted to receive mail for this domain; a sending server checks the certificate presented matches one of these.
• max_age – how long (in seconds) a sending server should cache this policy before re-checking. 604800 is a week.

How a Sending Server Uses This

Before delivering mail, a sending server that supports MTA-STS looks up _mta-sts.example.com, sees a policy exists, fetches the policy file over HTTPS, and then requires that its connection to your mail server negotiates TLS successfully with a certificate matching your listed MX hosts. If any of that fails – no TLS, wrong certificate, expired cert – and the mode is enforce, the message doesn’t get delivered rather than silently downgrading.

TLS Reporting (TLS-RPT)

MTA-STS is usually deployed alongside TLS-RPT, a companion DNS record that asks other mail servers to send you reports about delivery failures they experienced trying to reach you securely:

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Without this, you’d have no visibility into how often connections are failing your policy – which matters, because a misconfigured MX or an expired certificate under enforce mode means mail to your domain silently stops arriving rather than bouncing back with an obvious error.

A Sensible Rollout

1. Publish the policy file with mode: testing and a TLS-RPT address.
2. Watch the reports for a couple of weeks to confirm every legitimate sending path negotiates TLS cleanly.
3. Switch to mode: enforce once you’re confident.

Next: CAA records, which control which certificate authorities are even allowed to issue certificates for your domain in the first place.