Summary

  • An MTA-STS TXT id signals that a sender should refetch a policy. It does not contain or sign the policy, prove that every sender fetched it, or revoke all older caches. For a supporting sender, the applied authority is a specific HTTPS-authenticated policy body with a known fetch time and unexpired max_age.
  • A reproducible enforcement decision joins policy-domain discovery, policy-host PKIX validation, exact policy bytes, cache lineage, MX traversal, STARTTLS and certificate evidence, queue state, retry and the final disposition. enforce is a transport rule for one sending MTA, not proof of delivery, end-to-end secrecy, mailbox identity or business permission.

Two senders can correctly disagree

The opening is a constructed test, not an incident report. The recipient believes the new policy is current because its web server and TXT record have changed. Sender A sees the new ID, authenticates mta-sts.<domain>, downloads the new file and starts a new cache interval. Its applied list includes the backup MX.

Sender B's refresh fails. RFC 8461 does not instruct it to discard yesterday's still-valid policy merely because live discovery is unavailable. If a non-expired cached policy exists, the sender must apply it. The newly resolved backup MX is absent from that older policy, so Sender B treats the candidate as invalid and defers delivery.

Neither decision can be audited from the recipient's current DNS and web page alone. The required object is the sender's decision-time state. “What is the policy now?” is the wrong first question. The better question is: “Which authenticated policy bytes was this sender entitled to apply at this attempt?”

The DNS ID is a change signal, not the rule

MTA-STS splits discovery from policy content. The TXT record at _mta-sts.<policy-domain> carries the version and a policy instance id. IANA registers those field names. Registration gives implementers a common vocabulary; it does not certify a particular record, sender or deployment.

The ID has one narrow operational job: a new value tells a supporting sender that it should fetch a new HTTPS policy. It is not a digest of the file. It does not bind the mx lines, mode or max_age. It does not show that the file was deployed before the TXT change, that every DNS view returned the same value, that every policy-host edge returned the same bytes or that every sender completed the fetch.

That distinction makes deployment order consequential. Change the policy body without changing the ID and many senders can keep an older cache until expiry. Change the ID before the new body and some senders can faithfully fetch the old file into a fresh lifetime. A monitoring system that records only the latest TXT answer records intention, not applied reality.

HTTPS authenticates one policy body

The policy file lives at the fixed well-known path on mta-sts.<policy-domain>. The sender authenticates the policy host through PKIX: the certificate must be in time, chain to a root the sender trusts and contain an identity valid for the policy-host name. SNI for this connection carries the policy host, not the eventual mail exchanger.

The body then supplies four operational fields: version, mode, max_age and, except for none, one or more allowed MX patterns. Those bytes—not the DNS ID—define the fetched rule set. A defensible cache record therefore stores the response bytes and hash, fetch time, parsed values, certificate chain, hostname result, trust-store epoch and expiry computation.

The split also creates an explicit first-contact limit. If a valid TXT signal is observed but HTTPS retrieval fails and the sender has no valid cached policy, it continues as though MTA-STS were not implemented. An attacker able to suppress first discovery or retrieval can preserve opportunistic delivery. MTA-STS reduces downgrade risk after authenticated policy acquisition; it does not turn unsigned DNS absence into authenticated non-existence.

max_age creates many legitimate presents

max_age is measured from each sender's successful fetch. It is not a global wall-clock deadline chosen once for the Internet. Ten senders can fetch the same file at ten times and therefore hold ten expiry instants. Regional resolver behavior, HTTPS reachability, retry schedules, process restarts and cache replication widen that distribution.

The result is not accidental inconsistency; it is the protocol's continuity mechanism. A valid cached policy must survive a failed live lookup or fetch. Otherwise an attacker could defeat enforcement by blocking refresh. The same mechanism also makes mistakes durable. A long-lived wrong MX pattern or malicious policy can remain authoritative to a sender after the recipient repairs its visible records.

This is why clean removal uses mode: none, a short lifetime, a new ID and a wait for every older maximum lifetime that may still overlap. Deleting TXT and HTTPS endpoints first is not revocation. It can strand senders with unexpired enforce policies and remove the very path needed to fetch the release.

enforce binds a delivery attempt to an MX and certificate

For a sender holding a valid policy, the allowed object is not “mail for this company.” It is a candidate MX hostname that matches one of the applied mx patterns and then completes STARTTLS with a valid PKIX identity for that hostname. A wildcard covers only one complete left-most label. *.example.net does not cover the apex or a.b.example.net.

The SMTP SNI name is the selected MX hostname. The certificate must be unexpired, chain to a sender-trusted root and carry a matching DNS identity. These checks do not authenticate a mailbox user or the visible message author. They show that one sending MTA reached an allowed next-hop name over one authenticated TLS connection.

Ordinary MX priority still matters. An invalid candidate is treated like a transiently unreachable host and the sender proceeds through candidates in normal order. A backup MX omitted from policy can therefore stay invisible during everyday operation and fail only when the primary is unavailable. A settings-page green mark that never exercises failover is not proof of a complete policy.

The queue is part of the authority chain

In enforce mode a sender must not deliver to a host that fails MX matching, STARTTLS or certificate validation. That prohibition still does not authorize an immediate final bounce. Before permanently failing the message, the sender must check DNS for an updated policy ID; otherwise ordinary transient-failure and retry rules apply.

The difference is material. A transient deferral preserves time for a recipient to repair policy, certificate or MX state. A permanent failure closes the transaction and shifts harm to the originator and recipient. Evidence must therefore include the queue ID, applied policy hash and expiry, candidate sequence, exact failure, next retry, updated-ID check and final disposition. A TLS log without the queue transition cannot establish what the transport decision did to the message.

Testing, enforcement and removal are different compatibility states

testing allows delivery despite validation failure and makes the failure reportable where TLSRPT is used. enforce changes the sending MTA's delivery behavior. none tells a sender to treat the domain as having no active MTA-STS policy. They are not maturity badges; they produce different local actions.

Publication cannot force a sender to join any of those states. The recipient expresses a policy, but only a sender that implements MTA-STS, discovers and authenticates the file, maintains a cache and applies the rules enters that compatibility set. A non-supporting sender is not made compliant by the recipient's declaration.

This is the operational form of a thin common specification and localized decision. The RFC fixes enough shared rules to make discovery and enforcement interoperable. Each sender proves adoption through running behavior. The recipient does not become a global transport governor; the sender does not get to mislabel a cache miss as authenticated policy.

TLS reports are testimony about a population

RFC 8460 adds a separate reporting channel. Participating senders can describe detected policies, aggregate successful and failed sessions and report failure types such as certificate or STARTTLS problems. Microsoft and Google expose current product surfaces for MTA-STS enforcement and transport reporting, showing that the standards have running consumers.

The reports remain bounded evidence. Coverage depends on which senders implement TLSRPT, which reports reach the destination and how organizations aggregate events. A daily count is not a receipt for an individual message. It does not prove that a message was delivered, read, preserved, confidential at every intermediary or authorized for a later action.

The useful reconciliation joins three surfaces: recipient publication, sender enforcement and reporter observation. A policy can be syntactically valid yet operationally absent at a sender. A sender can enforce an older valid cache while the recipient's checker displays a newer file. A report can show failures without revealing the full queue decision. Authority is reconstructed from their intersection, not awarded to whichever surface is easiest to query.

DANE and REQUIRETLS mark adjacent boundaries

SMTP DANE authenticates a different policy path through DNSSEC and TLSA. RFC 8461 explicitly prevents MTA-STS from overriding a failing DANE validation. A PKIX-valid MTA-STS path cannot be used as a downgrade escape from a stronger DANE failure.

REQUIRETLS is also different. It carries per-message originator intent across supporting relays. MTA-STS is recipient-domain policy applied by the sending MTA to deliveries for that domain; it does not express that one message is more sensitive than another. Neither mechanism produces end-to-end content encryption merely because every observed SMTP hop used TLS.

Separating these objects prevents policy laundering. “MTA-STS passed” must not become “the sender required confidentiality,” “the recipient accepted the message,” “the user received it” or “the transaction is approved.” The running proof ends at the action the mechanism actually controls.

A replayable policy decision

A useful evidence row is keyed by policy domain, sender, attempt and time. It records TXT bytes and ID, DNSSEC state and TTL; HTTPS bytes, content type, certificate and fetch result; policy hash, mode, MX patterns, fetch time and expiry; candidate MX order; SMTP SNI, STARTTLS and certificate result; DANE state; queue transition; refresh and updated-ID checks; TLSRPT correlation; and final disposition.

Negative tests should make the boundary visible: change policy bytes without changing ID; change ID before the body; block HTTPS with and without a valid cache; let a cache expire; fail the primary and reach the backup; serve a wrong policy-host certificate; serve a valid policy but wrong MX certificate; publish none; and attempt an MTA-STS pass after DANE failure.

The evidence standard is simple: the published record describes an offer; authenticated fetch creates a bounded policy object; cache state gives that object a local lifetime; the actual SMTP path tests it; queue behavior reveals its consequence. No field deserves authority beyond that chain.

Sources