SMTP MTA Strict Transport Security (MTA-STS)
Extracted elements (30)
Implementers are advised against a 'two-pass' model that pre-filters the MX candidate list by policy validity before attempting delivery, as this risks message loops and incorrect behavior. Instead, implementers should traverse MX candidates in the normal priority order, treating MTA-STS-invalid candidates as transiently unreachable.
MTA-STS includes a 'testing' mode to enable soft deployments where senders report failures without blocking delivery. This allows policy authors to verify correct configuration before switching to 'enforce' mode, a capability not available in DANE which only supports partial deployment via per-MX TLSA records.
MTA-STS uses PKIX-based certificate authentication rather than DNSSEC (as used by DANE) to avoid requiring DNSSEC deployment. This trades the ability to authoritatively determine 'no record' (a DANE/DNSSEC feature) for broader deployability, at the cost of vulnerability to CA compromise and policy-discovery downgrade attacks.
The 'none' mode allows Policy Domains to authoritatively signal opt-out of MTA-STS, distinguishing deliberate removal from attack-induced policy absence. The recommended removal workflow publishes 'mode: none' with a short max_age, then waits for all previously cached policies to expire before removing DNS and HTTPS endpoints.
The SMTP client MUST have support for TLS SNI (RFC 6066). When connecting to the HTTPS policy server, SNI MUST contain the Policy Host name (e.g., 'mta-sts.example.com'). When connecting to SMTP servers, SNI MUST contain the MX hostname. SMTP servers MUST NOT enforce the use of SNI by clients, and MUST send a fallback certificate chain if no SNI is provided.
If a valid TXT record is found but no policy can be fetched via HTTPS and there is no valid non-expired cached policy, senders MUST continue delivery as though the domain has not implemented MTA-STS. Conversely, if no live policy is discoverable but a valid cached policy exists, the sender MUST apply that cached policy.
If the number of valid '_mta-sts' TXT records (after discarding those not beginning with 'v=STSv1;') is not exactly one, or if the resulting record is syntactically invalid, senders MUST assume the recipient domain does not have an available MTA-STS Policy and skip the remaining steps of policy discovery.
In 'enforce' mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS. When a message fails due to an enforce policy, a compliant MTA MUST NOT permanently fail delivery before checking via DNS for the presence of an updated policy.
MTAs SHOULD proactively refresh cached policies before they expire (suggested: once per day), and SHOULD alert administrators when refresh attempts fail (unless the cached policy mode is 'none'). Policy 'max_age' values SHOULD be as long as practical to reduce the window of vulnerability during policy discovery attacks.
MTAs supporting MTA-STS MUST have support for TLS 1.2 (RFC 5246) or TLS 1.3 (RFC 8446) or higher. The general TLS usage guidance in RFC 7525 SHOULD be followed.
Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in RFC 7234) MUST NOT be used when fetching MTA-STS policies.
Senders implementing both MTA-STS and TLSRPT MUST NOT allow MTA-STS Policy validation to override a failing DANE validation. MTA-STS is designed not to interfere with DANE deployments when the two overlap.
The certificate presented by the receiving MTA MUST not be expired, MUST chain to a root CA trusted by the Sending MTA, and MUST have a subject alternative name (SAN) with a DNS-ID matching the MX hostname per RFC 6125 rules.
The Policy Host HTTPS server MUST present an X.509 certificate valid for the 'mta-sts' DNS-ID (e.g., 'mta-sts.example.com'), chaining to a root CA trusted by the Sending MTA, and must be non-expired. Matching is performed only against DNS-ID identifiers per RFC 6125.
When fetching a policy, senders SHOULD validate that the media type is 'text/plain' to guard against cases where web servers allow untrusted users to host non-text content at user-defined paths. HTTPS policy fetch failures SHOULD be rate-limited to at least five minutes per version ID to avoid overwhelming recipients.
When sending mail via a smart host, compliant senders MUST treat the smart host domain as the Policy Domain. When sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone.
MTA-STS policy discovery uses two components: a DNS TXT record at '_mta-sts.<domain>' (e.g., '_mta-sts.example.com') containing version and policy ID fields, and an HTTPS-hosted policy file at 'https://mta-sts.<domain>/.well-known/mta-sts.txt'. The TXT record allows senders to detect policy presence and check for updates without fetching the full policy.
MX host validation requires that the MX record name matches one or more 'mx' patterns in the applied policy. Wildcard '*' may only match the entire left-most label; '*.example.com' matches 'mail.example.com' but not 'example.com' or 'foo.bar.example.com'. Internationalized domain names must use Punycode A-labels.
Policy delegation allows domain owners to delegate MTA-STS to a hosting provider by (1) pointing '_mta-sts' via CNAME to the provider's TXT record, and (2) pointing the 'mta-sts' hostname to the provider (via IP/CNAME or reverse proxy). The policy endpoint must always present a certificate valid for the delegating domain's Policy Host, not the provider's.
The policy 'mode' field controls Sending MTA behavior on validation failure: 'enforce' prohibits delivery to non-compliant MX hosts; 'testing' allows delivery but requires TLSRPT failure reporting; 'none' instructs senders to treat the domain as having no active policy, used for clean opt-out.
IANA created a new 'MTA-STS Policy Fields' registry with initial entries for 'version', 'mode', 'max_age', and 'mx'. New fields are added via IANA's Expert Review policy.
IANA created a new 'MTA-STS TXT Record Fields' registry with initial entries for 'v' (record version) and 'id' (policy instance ID). New fields are added via IANA's Expert Review policy.
IANA registered a new well-known URI with suffix 'mta-sts.txt' in the Well-Known URIs registry, with IETF as the Change Controller.
An attacker who can modify DNS records for a recipient domain can advertise a malicious long-lived MTA-STS Policy with MX constraints that validate attacker-controlled hosts, causing senders to cache the malicious policy and refuse delivery after the victim regains control of DNS. The victim can mitigate this by publishing an updated policy at any time.
MTA-STS is vulnerable to policy-discovery suppression attacks: an attacker who can block DNS responses can prevent senders from discovering the MTA-STS policy, effectively downgrading security. The sender policy cache mitigates this by reducing discovery frequency; proactive pre-expiry refresh further reduces the attack window.
MTA-STS relies on PKIX certificate validation; attackers who obtain a valid certificate for the targeted mail service (e.g., by compromising a CA) can circumvent STS authentication entirely. This is a known limitation versus DNSSEC/DANE. Implementers are recommended to support certificate revocation via OCSP or CRLs.
Weak 'mx' policy patterns (e.g., '*.example.com') can allow any host in the domain with a valid CA-signed certificate to be treated as a valid MX by MTA-STS validation, including dynamically assigned or user-controlled hostnames. Policy authors must carefully scope MX patterns.
Policy application control flow: (1) check for a non-expired cached policy, else attempt to fetch a new one; (2) for each candidate MX in priority order, attempt delivery enforcing STARTTLS and certificate validity if mode is 'enforce', skipping failing candidates; (3) a message delivery attempt MUST NOT be permanently failed until the sender has checked for a new policy via the '_mta-sts' TXT 'id' field.
The MTA-STS policy file is a CRLF-separated key/value text resource served via HTTPS GET. Required fields are 'version' (STSv1), 'mode' (enforce/testing/none), 'max_age' (non-negative integer seconds, max 31557600), and one or more 'mx' patterns. Each MX pattern must appear on its own line with its own 'mx:' key.
The '_mta-sts' TXT record is a US-ASCII, semicolon-separated key/value string. Required fields are 'v' (must be 'STSv1') and 'id' (1–32 alphanumeric characters uniquely identifying the policy instance). The record MUST begin with the version field; records not beginning with 'v=STSv1;' are discarded.