Define first connection by sender policy state
MTA-STS cannot guarantee protection for every initial delivery to a domain. Its strongest downgrade resistance depends on a supporting sender already holding a valid policy that requires enforcement. “First connection” is therefore better understood as a policy-state question than as the first message ever sent by a person. Another machine, a cleared cache or an expired policy can change the starting conditions.
This explanation uses a fictional state comparison, not a live downgrade experiment. No traffic was intercepted, DNS response altered or sending system tested. Demonstrating a particular implementation's behavior requires an approved isolated test with evidence of its initial cache, discovery results, policy mode and delivery decision.
Explain why discovery is the vulnerable step
A receiving domain advertises MTA-STS through a DNS TXT record and serves its policy over HTTPS. The authenticated HTTPS fetch establishes the policy's contents, but an attacker who can prevent successful initial discovery can keep a sender from learning those contents. RFC 8461 explicitly describes this discovery-prevention risk. A securely hosted policy does not help a sender that has not obtained it. RFC 8461 sections 3 and 10.2
The specification requires a sender with no valid cached policy to continue as though MTA-STS were not implemented if a valid discovery record exists but HTTPS retrieval fails. It also permits policy acquisition to occur asynchronously in its example control flow. Publishing an enforce policy does not establish that every supporting sender has fetched it before its next delivery. RFC 8461 sections 3.3 and 5.1
Distinguish ordinary TLS from enforced policy
SMTP STARTTLS provides a way to negotiate TLS on a connection. The extension alone does not establish the receiving domain's MTA-STS requirements. RFC 3207 discusses the limitations of opportunistic operation and the importance of local policy when TLS cannot be negotiated or authenticated. Avoid equating a STARTTLS advertisement with a guarantee that a sender will reject every unsafe fallback. RFC 3207 sections 5 and 6
Once a supporting sender applies a valid enforce policy, it must not deliver to a candidate that fails the required MX matching or certificate validation, or lacks STARTTLS. Testing mode differs: messages may be delivered despite MTA-STS validation failure, with reporting where implemented. A cached policy therefore matters together with its mode; merely having a cache entry is not synonymous with enforcement. RFC 8461 section 5
Compare three fictional senders
Assume fictional example.com publishes an enforce policy for mx1.example.com. Sender Alder has no valid cached policy and cannot retrieve one. Sender Birch has a valid, unexpired enforce policy obtained earlier. Sender Cedar has only an expired policy and cannot refresh it. These are constructed states for explanation, not measurements of named products.
Alder continues without MTA-STS protection after the failed acquisition. Birch must continue applying its cached enforce policy even when current discovery or retrieval is unavailable. Cedar cannot treat its expired entry as the valid cached policy required by this protection rule. None of these statements rules out other constraints imposed by DANE or local transport requirements. The example distinguishes MTA-STS's contribution from the sender's entire security posture. RFC 8461 sections 3.3 and 5.1
Now suppose the contacted SMTP host fails certificate validation. Birch cannot deliver to that failing candidate under enforce mode and should follow the specified retry and updated-policy checks. Alder's outcome cannot be predicted from the missing MTA-STS policy alone: its other policies and SMTP implementation still matter. Calling all three outcomes “encrypted” or “blocked” would hide the deciding evidence. RFC 8461 sections 4–5
Describe what caching improves and what expires
Policy max_age limits how long a fetched policy remains usable. RFC 8461 expects lifetimes commonly measured in weeks or more to reduce refresh-time exposure, and recommends proactive refresh before expiration. That creates a tradeoff: longer-lived policies preserve protection through temporary discovery failures but demand care when changing MX infrastructure. An unavailable old MX does not become acceptable just because a new configuration is intended. RFC 8461 sections 3.2–3.3 and 8.1
Deleting discovery records does not immediately remove policies already cached by senders. The documented opt-out uses a valid mode none policy, a new discovery ID and enough time for previously served policies to expire before removing endpoints. Operational rollback must account for those remote states. A local DNS change cannot retroactively prove that every remote sender has abandoned its cache. RFC 8461 section 8.3
Position DANE and reporting accurately
DANE for SMTP uses DNSSEC-authenticated TLSA information to provide a different basis for authenticating TLS. RFC 8461 presents MTA-STS as complementary and states that it must not override a failing DANE validation. DANE's applicability depends on its authenticated DNS chain, usable records and sending implementation; it should not be presented as a switch that this article has configured or tested. RFC 8461 section 2 RFC 7672
TLS-RPT helps participating senders describe transport and policy failures, but reporting is not enforcement. Reports cover a reporter's observations and can arrive after the event. A missing report cannot prove that discovery succeeded, a cache existed or all paths were protected. Use reports alongside sender-state and connection evidence, not as a substitute for them. RFC 8460 sections 1 and 4
State a defensible protection claim
A useful claim identifies supporting senders, valid policy acquisition, enforce mode, applicable MX scope and remaining first-acquisition exposure. Avoid “all incoming email is downgrade-proof.” An approved evaluation should demonstrate empty-cache, valid-cache and expired-cache behavior while holding the intended scenario constant. The actual implementations, traces and results are absent here. Current RFC errata were checked, but no reported proposal has been elevated into a new protection guarantee. RFC 8461 errata