MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard defined in RFC 8461 that lets a domain publish a policy requiring sending mail servers to use validated TLS when delivering email. It closes the gap left by STARTTLS, which can be silently stripped by a network attacker.

The Problem: STARTTLS is Opportunistic

SMTP servers signal TLS support by advertising STARTTLS in their capability list. A sending server that sees STARTTLS will upgrade the connection — but this negotiation happens in plaintext and is unauthenticated. An active attacker positioned between the two servers can remove the STARTTLS advertisement from the capability response, causing the sender to deliver mail in plain text without either party noticing. This is a STARTTLS downgrade attack.

MTA-STS removes the attacker's opportunity by letting the receiving domain pre-publish a policy: "always use TLS when connecting to my mail servers, and validate the certificate." A sending server that has fetched this policy will refuse to deliver mail over a non-TLS or certificate-invalid connection.

How MTA-STS Works

MTA-STS uses two published artifacts: a DNS TXT record and an HTTPS-served policy file.

The DNS record at _mta-sts.<domain> signals that a policy exists and carries an id field that changes whenever the policy is updated:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20240101120000Z"

The policy file is served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt with a Content-Type: text/plain header. A typical policy file looks like this:

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

A sending MTA fetches and caches the policy (for up to max_age seconds). On subsequent deliveries it checks the id field in DNS; if the id has changed, it re-fetches the policy file. Caching means that even if DNS is temporarily compromised, previously fetched policies still protect delivery.

Policy Modes

• none — signals that the domain has no active MTA-STS policy; senders should not apply MTA-STS. Primarily used to cleanly retire a previously published policy.
• testing — senders validate TLS but deliver mail even when validation fails. Failures are reported via TLS-RPT. Use this mode to observe failures before switching to enforcement.
• enforce — senders must abort delivery if TLS cannot be established or the certificate does not match. Mail is queued and retried rather than delivered insecurely.

Pairing with TLS-RPT

TLS Reporting (TLS-RPT, defined in RFC 8460) is a companion mechanism that lets receiving domains collect JSON reports from sending servers about TLS connection failures. To enable it, publish a TXT record at _smtp._tls.<domain>:

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

Senders that support TLS-RPT will send daily aggregate reports to the address in the rua field. These reports are invaluable when running in testing mode — they show which sending servers are failing to establish TLS and why, letting you fix MX certificate issues before enabling enforcement.

Deployment Checklist

• Your MX hosts must serve a certificate that is valid (trusted CA, not expired) and matches the hostnames listed in the policy's mx fields.
• The mta-sts.<domain> subdomain must itself have a valid TLS certificate — the policy file is fetched over HTTPS.
• Start in testing mode, collect TLS-RPT data for at least a few weeks, resolve any certificate mismatches, then switch to enforce.
• Update the id value in the DNS TXT record whenever you change the policy file. Sending servers use the id to know when to re-fetch.

Check MTA-STS with the DNS mail audit →