Use TLS reports to locate negotiation failures, then reproduce the handshake safely before changing supported protocol settings.
Do not infer a cipher problem from a generic label
References: RFC 8460 §4.3.1.
TLS-RPT has starttls-not-supported and a general validation-failure category, but a generic failure is not proof that the receiver disabled a particular protocol or cipher. RFC 8460 recommends failure-reason-code for additional context. Preserve that text with the reporting MTA and endpoint. Distinguish failure to advertise STARTTLS, failure to begin the handshake, certificate validation failure and failure after authentication. These stages require different evidence and should not all become a dashboard label such as TLS broken.
Verify the SMTP path rather than a web service
References: RFC 3207 §4.
SMTP STARTTLS upgrades an SMTP connection after protocol negotiation; testing an HTTPS endpoint does not exercise that path. Use an authorised diagnostic connection to the actual receiving host and service. Record the greeting, EHLO capability response, STARTTLS response and handshake result without sending real message content unnecessarily. Compare the implicated address and receiving route with production configuration. Middleboxes and alternate listeners can change what the sender sees, so a test from one network is evidence for that path, not every reporter’s path.
Use a compatibility model with honest limits
References: RFC 8446 §4.1.3, RFC 8446 §4.2.1.
The synthetic fixture assigns sender-supported versions {TLS1.2, TLS1.3} and receiver-supported versions {TLS1.3}. Their intersection is nonempty, so the simplified model has a common version. Change the sender set to {TLS1.2}; the intersection is empty. This demonstrates one necessary compatibility condition, not a successful handshake. Cipher suites, signature algorithms, certificate properties, groups and implementation policy can still prevent negotiation even when a version overlaps. Do not publish the model’s output as tested interoperability between named mail products.
Change settings from an approved security baseline
References: RFC 9325 §3.1.1.
Compare the actual negotiated failure with vendor documentation and your security policy. Avoid enabling obsolete protocols or weak algorithms solely because a report contains failures. If a legitimate sender cannot meet the receiving baseline, investigate upgrades and the operational impact with its owner. Changes to transport security require a deliberate risk decision, staged rollout and rollback plan, rather than an automatic reaction to an aggregate count. Keep the previous configuration and capture the exact setting that changed.
Validate repair without overclaiming coverage
References: RFC 8460 §4.3.4.
Repeat the same authorised path test after the change and record the negotiated version and relevant validation outcome. Exercise backup listeners and address families that participate in the affected route. Compare later TLS-RPT periods for the same reporter and policy domain, recognising that transient TCP and busy-network errors are not required to be reported by RFC 8460. An empty failure list therefore cannot prove the whole network is reliable. No production SMTP connection or production security-setting change was performed. The controlled loopback evidence below extends the set-intersection model with actual TLS handshakes.
Retained historical evidence and current checks
The transport observations below were captured on 7 November 2026 and inspected, not rerun as network tests, for this review. The new offline model checks are recorded separately.
The retained controlled SMTP STARTTLS capture tests a server requiring TLS1.3 against a client limited to TLS1.2. The handshake fails with TLSV1_ALERT_PROTOCOL_VERSION at the client and UNSUPPORTED_PROTOCOL at the server. A compatible positive control negotiates TLSv1.3. Recorded SMTP exchanges show that STARTTLS was advertised and accepted before the TLS failure. This distinguishes a protocol incompatibility from missing STARTTLS without changing production settings. It does not establish named-provider interoperability. The historical transport runner requires Python with cryptography and loopback sockets. Its outcomes are bounded lab evidence, not current service health or production interoperability.
Primary-source basis
The field definitions and reporting limits come from RFC 8460, SMTP TLS Reporting, sections 3 and 4. Where STS validation is discussed, consult RFC 8461. The operational recommendations are distinguished from protocol requirements.