Distinguish expiry from trust-chain failure, preserve the reported endpoint and validate the certificate actually served after renewal.
Read the result category precisely
References: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
certificate-expired means the reporter observed an expired certificate. certificate-not-trusted covers several conditions, including unknown certification authorities, chain errors and name constraints. The failure-reason-code may narrow the diagnosis but is reporter-provided text, not a universal parser contract. Do not label every certificate-not-trusted report as a missing intermediate without evidence. Start with the policy context and reported receiving endpoint so that an SMTP certificate problem is not confused with sts-webpki-invalid on an MTA-STS HTTPS policy host.
Check the certificate that reached the sender
A certificate manager showing a renewed certificate does not establish that every SMTP listener serves it. Record serial or fingerprint, validity interval, chain and test timestamp from the actual authorised endpoint check. Compare those values across the receiving routes implicated by reports. A stale process, forgotten backup host or incomplete load-balancer deployment can leave old certificates active. Review clock accuracy when validity boundaries appear inconsistent, but do not change clocks or trust stores merely to make a failing test pass.
Reproduce a renewal overlap problem
The synthetic exercise defines an old certificate valid until t=100 and a new one valid from t=90 until t=200. At t=110, a listener still serving the old certificate fails the model’s validity-window check, while a listener serving the new certificate passes it. This reproduces the deployment distinction without generating a real certificate. It does not prove chain trust, name matching, revocation behavior or the implementation’s boundary conventions. Those need a real TLS validator and controlled endpoint evidence.
Investigate trust without bypassing it
References: RFC 8461 §4.2, RFC 7672 §3.1.1.
Capture the leaf and served intermediate chain, then compare the reporter’s reason with a maintained test environment. An issuer trusted by one local machine may not be accepted by the affected sender. Missing intermediates, an unexpected self-signed certificate and a policy-specific constraint are different repairs. Document the selected validation model. SMTP DANE with DANE-EE usage has different trust semantics from Web PKI, so an STS-style conclusion about public certification authorities cannot simply be applied to every TLSA report.
Close the loop on deployment and reporting
References: RFC 8460 §4.1.
Apply the approved renewal or chain correction to each affected listener, verify reload behavior and retain evidence of the presented certificate after the change. Compare reports whose observation periods fall after the repair and account for aggregation delays. Schedule renewal monitoring with enough lead time for ownership and rollout, and separately monitor whether the new certificate is actually deployed. Do not automatically lower an enforcing transport policy to hide certificate failures. This guide records controlled lab tests only; it does not renew production certificates, alter production trust stores or demonstrate production recovery.
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 loopback capture includes a certificate signed by the trusted lab CA whose validity ended before the test; it fails with verify code 10, certificate has expired. A separate self-signed leaf fails with verify code 18, self-signed certificate. The valid control succeeds with the same expected hostname. Timestamped handshake evidence and public certificates are retained, allowing expiry and trust failures to be inspected separately. Private keys are temporary and removed. Actual service renewal rollout and all-listener deployment verification remain outside this lab. 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.