MTA-STS (SMTP MTA Strict Transport Security, RFC 8461)

MTA-STS (RFC 8461) lets a receiving domain declare that it supports TLS for inbound SMTP and that sending MTAs should refuse to deliver to it over insecure channels. It closes the classic STARTTLS weakness: because STARTTLS is negotiated in cleartext, an active attacker can strip it (downgrade) or impersonate the MX. MTA-STS gives senders an out-of-band, cached policy to detect both.

Unlike DANE for SMTP, MTA-STS does not require DNSSEC. It leans on the Web PKI (CA-signed certificates) and HTTPS instead — easier to deploy, but weaker against attackers who can tamper with DNS on first contact (see Security model below).

Roles

• Policy Domain — the recipient domain publishing the policy (the RFC5321 mail domain, i.e. the part after @).
• Sending MTA — discovers, caches, and applies the policy when delivering to that domain.

Policy discovery: the DNS TXT record

The presence (and version) of a policy is signaled by a TXT record at _mta-sts.<policy-domain>:

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

Processing rules:

• Fields are semicolon-separated key/value pairs; unknown fields are ignored.
• If multiple TXT records are returned, discard any not beginning with v=STSv1;. If more than one valid record remains, the result is ambiguous (misconfiguration).
• Multiple character-strings in one record are treated as concatenated.
• CNAMEs at _mta-sts.<domain> are followed normally (this enables delegation — see below).

The TXT record only announces a policy and its version. The policy content itself lives at the HTTPS endpoint.

Policy retrieval: the HTTPS well-known endpoint

The policy is fetched with an HTTPS GET from a "Policy Host" formed by prepending the literal label mta-sts to the Policy Domain:

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

Fetch requirements:

Policy file format

CRLF-separated key: value pairs:

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

Parsing: unknown fields are ignored (extensibility); for duplicated non-repeatable fields (everything except mx), only the first occurrence counts.

MX matching rules

A candidate MX host is valid if its MX record name matches one of the mx patterns (RFC 6125 rules, wildcard restricted to the entire left-most label):

The three modes

Sender-side requirements

• MUST support TLS 1.2 or higher.
• MUST support the TLS SNI extension.
• The receiving MTA's certificate MUST be non-expired, MUST chain to a root CA trusted by the sender, and MUST contain a SAN DNS-ID matching the host per RFC 6125. Revocation MAY be checked (OCSP, CRLs).

Caching and refresh

• Cache a fetched policy for up to max_age seconds from the last fetch.
• Before permanently failing a delivery under an enforce policy, check DNS for a newer policy (changed id) — the recipient may have fixed a broken policy.
• SHOULD refresh proactively (e.g., a daily background fetch) rather than waiting for expiry — this shrinks the window in which an attacker can block discovery.
• If the TXT record is found but the policy fetch fails and no valid cached policy exists: continue delivery as if MTA-STS were not implemented (fail open on first contact).
• If no live policy is discoverable but a valid, unexpired cached policy exists: apply the cached policy (this is the core downgrade protection).

Security model

MTA-STS is trust on first use: until a sender has cached a policy, an attacker who can block DNS responses or the HTTPS fetch can make the domain appear policy-free. Once cached, the policy protects deliveries for max_age — hence the RFC's guidance that max_age SHOULD be "as long as is practical".

DoS vector: an attacker who can modify a recipient domain's DNS can publish a malicious policy (long max_age, wrong mx constraints) that senders cache. Recovery relies on senders re-checking DNS before permanent failure.

Contrast with DANE: DANE (DNSSEC-backed) is more downgrade-resistant; MTA-STS trades that for deployability (no DNSSEC needed). Per RFC 8461: senders implementing both MUST NOT allow MTA-STS validation to override a failing DANE validation — see DANE for SMTP.

Operational playbook

Deploying:

1. Ensure every MX presents a valid CA-signed cert with matching SAN and offers STARTTLS.
2. Publish the policy file first, then the _mta-sts TXT record (senders seeing a new TXT id must not cache a stale policy).
3. Start with mode: testing and a modest max_age; enable TLS-RPT and watch reports.
4. Move to mode: enforce and lengthen max_age once reports are clean.

Updating (e.g. changing MX hosts): update the HTTPS policy body before the TXT id. Keep old policies working for delivery during the transition window (up to the old max_age) or risk delays.

Removing MTA-STS gracefully:

1. Publish a policy with mode: none and a small max_age (e.g., one day).
2. After previously cached policies have expired, remove the TXT record and the HTTPS endpoint.

Delegating to a provider: CNAME _mta-sts.<yourdomain> to the provider's TXT record, and point the mta-sts.<yourdomain> host at the provider (CNAME/IP or reverse proxy). The catch: the policy endpoint's certificate must validate for your Policy Host name (mta-sts.yourdomain.com), not the provider's — the provider must provision a cert for your name.

Why deliverability senders care

MTA-STS is a receiving-domain control, but senders are on both sides of it:

• As a sending platform, honoring recipient MTA-STS policies (and not delivering through failing paths) is increasingly expected of reputable infrastructure, and failures show up in the recipient's TLS-RPT data.
• As a domain owner, publishing MTA-STS + TLS-RPT on your own domains is a trust signal consistent with the authentication posture mailbox providers now demand (see DMARC) and protects mail you receive (including DMARC/TLS reports and reply traffic) from interception.