STARTTLS is a mechanism for upgrading an SMTP connection to TLS. It does not by itself say whether TLS was required, whether the peer was authenticated or whether a failed negotiation could fall back to plaintext. Those are policy questions. A useful transport assessment records each separately rather than reducing them to a single green padlock.
Read the negotiation in order
References: RFC 3207 §4.
An SMTP client establishes a connection, sends EHLO and reads the server's extensions. A STARTTLS advertisement offers the upgrade. When the client requests it and receives the readiness response, TLS negotiation begins. After the handshake, SMTP state is reset and the client should issue EHLO again; capabilities learned before TLS are not simply carried forward. RFC 3207 section 4.
A transcript containing the word STARTTLS is not enough. Identify the server response, handshake outcome and negotiated protocol. A successful handshake establishes encryption on that connection, but its authentication strength depends on certificate verification and policy. Record why the sender accepted the peer, not only which cipher was negotiated.
Understand opportunistic behavior
References: RFC 3207 §6.
Opportunistic TLS attempts encryption when it is available without necessarily requiring authenticated TLS for every destination. Local sender policy can be stricter, so avoid assuming all systems behave the same way on failure. Absence of a universal enforcement rule is what makes a bare STARTTLS capability a limited security claim.
In particular, an active attacker may suppress a STARTTLS advertisement on an otherwise unauthenticated path. If the sender has no independent requirement for TLS, the missing advertisement can lead to unencrypted delivery. Modern encryption algorithms do not fix a negotiation that never reaches TLS. See the attack discussion in RFC 3207 section 6.
Add an authenticated policy decision
References: RFC 8461 §4, RFC 8461 §5, RFC 7672 §2.2.
A supporting sender with an applicable enforcing MTA-STS policy checks the receiving MX and certificate requirements and must not deliver in violation of that policy. Testing mode does not require withholding delivery for an MTA-STS validation failure; failure reporting depends on TLS-RPT being implemented by the sender and receiving domain. SMTP DANE uses secure TLSA discovery and its certificate-usage rules to establish the transport requirement. Do not call either control active just because the receiving domain published something that the sender never evaluated.
A synthetic decision model uses one route with three inputs: STARTTLS advertised, handshake successful and peer accepted under the applicable policy. It records an opportunistic encrypted connection separately from a policy-compliant connection. A negative case removes STARTTLS while enforcement is active and expects no delivery on that route. The fixture is a decision illustration, not an SMTP implementation or packet capture.
Report precisely and retest failures
For a real check, retain the sender, destination IP, timestamp, route selection, policy state and verification result. An OpenSSL STARTTLS probe can inspect a selected endpoint, but it does not automatically reproduce the sending MTA's DNSSEC discovery, MTA-STS cache or failover policy. Follow a controlled sender-side test with logs that establish the actual decision.
Use wording such as encrypted connection observed, authenticated peer verified, or enforcing sender rejected the noncompliant route. Do not claim every message is protected because one connection succeeded. The review package now includes retained 7 November 2026 loopback transcripts. Successful controls record pre-TLS EHLO, STARTTLS readiness and post-TLS EHLO. One configured trust test presents certificate B while the client trusts A and records self-signed-certificate verification failure; its A control succeeds. A required-TLS client refuses a server without STARTTLS. These are historical controlled Python-client decisions, not a production MTA or complete MTA-STS/DANE implementation. In particular, configured trust and association inputs do not establish a DNSSEC chain, live policy discovery, every required certificate-profile constraint or real sender caches. No MAIL FROM, RCPT TO or DATA command is sent. The captures were inspected, not rerun as network tests for this review. The new offline fixture checks only its explicitly defined decision model.