SMTP commonly upgrades a plaintext connection with STARTTLS. Without an authenticated transport policy, that upgrade can remain opportunistic: a sender may continue delivery when TLS is unavailable, depending on its configuration. An active intermediary that can interfere with the SMTP exchange can exploit that flexibility by suppressing the STARTTLS capability or redirecting delivery.
MTA Strict Transport Security (MTA-STS), defined by RFC 8461, gives a recipient domain a policy that compliant sending MTAs can cache and enforce. The policy states which MX hosts are acceptable and whether delivery requires TLS with a certificate that passes PKIX validation.
The mechanism does not encrypt stored mail, authenticate message authors, or replace anti-spam controls. Its scope is the SMTP transport between sending and receiving systems.
DNS signals policy state while HTTPS carries the policy
A domain signals MTA-STS with a TXT record under _mta-sts:
_mta-sts.example.net. TXT "v=STSv1; id=2026092401"The v field identifies the MTA-STS record format. The id field is an opaque value that changes when the published policy changes. A sending MTA can compare that value with the identifier associated with its cached policy and fetch a newer policy when needed.
The policy itself is retrieved over HTTPS from a fixed host and path:
https://mta-sts.example.net/.well-known/mta-sts.txtRFC 8461 requires HTTPS policy retrieval with certificate validation. DNS signals that a policy exists and provides update signaling; HTTPS carries the policy body.
This split has an operational consequence: changing only the TXT record or only the HTTPS document can leave senders with different cached states. Policy updates need coordination between both surfaces.
The policy binds delivery to declared MX hosts
A minimal policy can look like this:
version: STSv1
mode: enforce
mx: mail.example.net
max_age: 604800version identifies the policy syntax. Each mx field supplies an acceptable MX hostname pattern. max_age states, in seconds, how long a sender may treat the fetched policy as valid.
When an active policy is applied, the selected MX must match at least one policy mx pattern. The SMTP server must also offer STARTTLS, and the TLS certificate presented by that server must satisfy the certificate validation rules in RFC 8461.
The policy therefore constrains two distinct decisions: the destination host and the authenticated TLS session to that host. A valid certificate on an MX that is outside the policy does not satisfy the policy, and an allowed MX without acceptable TLS does not satisfy it either.
Policy modes separate rollout from enforcement
MTA-STS defines three policy modes:
mode: testing
mode: enforce
mode: noneIn enforce mode, a compliant sender must not deliver to an MX that fails policy validation. It can try another candidate MX, but a policy failure is not permission to fall back to an unauthenticated plaintext session.
testing keeps delivery behavior permissive when MTA-STS validation fails. It is intended to expose policy problems before strict enforcement. When SMTP TLS Reporting is also deployed, failures can be reported under the TLSRPT mechanism defined by RFC 8460.
none indicates that the domain has no active MTA-STS policy. RFC 8461 also uses this mode in the removal procedure so cached policies can age out in a controlled manner before the signaling record and policy endpoint disappear.
A rollout can therefore move from observation to enforcement without treating the first policy publication as an irreversible switch.
Cached policy is part of the security boundary
MTA-STS does not require DNSSEC for its TXT signal. That makes initial policy lookup a sensitive point. An attacker able to suppress the first _mta-sts response can make a domain appear to have no policy to a sender that has never cached one.
Caching narrows that exposure after a successful policy fetch. Once a sender has a valid policy, transient interference with DNS does not automatically erase the cached requirement. The sender can continue applying the policy until its validity period expires, subject to the update and refresh behavior defined by the specification.
This property also makes max_age more than a convenience setting. A longer value extends the period during which a previously authenticated policy can survive lookup interference, while also increasing the care required when changing or retiring policy.
MTA-STS is therefore not equivalent to DANE for SMTP. DANE uses DNSSEC-authenticated TLSA data for SMTP server authentication. MTA-STS uses HTTPS-delivered policy and PKIX certificates, with DNS serving as lookup and change signaling. RFC 8461 specifies that MTA-STS validation must not override a failing DANE validation when both mechanisms are in use.
Certificate validation is tied to the MX identity
An MTA-STS sender does not merely check that some certificate was presented. The TLS connection has to authenticate an acceptable server identity for the selected MX according to the policy’s validation rules.
That requirement turns certificate lifecycle errors into mail-delivery risks under enforce. An expired certificate, a name mismatch, a broken chain, or a deployment that removes STARTTLS can prevent a compliant sender from delivering to that MX.
The operational response is not to weaken the sender. The receiving side needs certificate renewal, MX configuration, and policy changes to remain coordinated. A policy that names retired hosts or omits active hosts can cause the same class of delivery failure even when TLS itself is configured correctly.
TLSRPT adds visibility without changing the enforcement rule
SMTP TLS Reporting is a separate mechanism defined by RFC 8460. A recipient domain can publish a TLSRPT reporting destination under _smtp._tls and receive aggregate information about successful TLS negotiation and specified failure categories.
MTA-STS does not depend on a report arriving before it enforces policy. TLSRPT is observability around transport policy, not an authorization channel. Its value is operational: repeated certificate, MX, policy-fetch, or STARTTLS failures can become visible instead of appearing only as remote delivery retries.
That distinction matters during testing mode. Reports can reveal a policy that does not match the deployed mail topology before the same mismatch becomes delivery-blocking under enforce.
Removal needs to respect cached senders
Deleting the _mta-sts TXT record is not sufficient to retract a policy already cached elsewhere. A sender may continue applying the cached policy until its max_age expires.
RFC 8461 describes a controlled removal path using a new policy with mode: none and a short max_age, accompanied by a new TXT id so senders can detect the change. The old policy endpoint and signaling record are removed only after previously served policies have had time to expire.
The same cache behavior that resists transient suppression also makes abrupt retirement unsafe. MTA-STS works as persistent transport state, not as a per-connection hint.
Its security value comes from that persistence. After a compliant sender has obtained a valid policy, SMTP delivery is no longer free to silently degrade whenever authenticated TLS fails. The recipient domain has published a durable constraint on acceptable MX hosts and transport authentication, and the sender carries that constraint across later delivery attempts.