A transport checker can discover a real problem without proving the security of every message your organisation sends or receives. Most checks observe a selected endpoint at a particular time using a particular resolver and validation method. A defensible result therefore includes scope and missing coverage, not just a pass badge.
Define the delivery route inventory
References: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
List the recipient domains, MX hostnames, priorities, IPv4 and IPv6 addresses, hosted gateways and failover routes. Note whether the test follows ordinary MX routing or an explicitly configured smart host. Record the sender implementation and whether it supports MTA-STS, DANE or a local mandatory-TLS policy. Different sending systems can make different decisions for the same receiving domain.
Then define the claim each check can support. A public HTTPS request can establish policy availability from that vantage point. A TLS probe can observe a presented certificate on a chosen address. A validating DNS query can provide evidence about DNSSEC status under a specified resolver trust model. None alone proves that a real sending MTA used the same data and enforced the expected delivery policy.
Capture state rather than just outcomes
References: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
For MTA-STS, retain the discovery record, exact HTTPS policy bytes, retrieval time, mode, lifetime and the sender's cache state. For DANE, retain the MX and TLSA answers, validation state and association comparison. For each SMTP connection, capture the selected host and IP, STARTTLS negotiation, peer verification result and delivery decision. RFC 8461 sections 3–5, RFC 7672 sections 2–3.
A failed probe should record its failure stage. DNS timeout, TCP timeout, absent STARTTLS, handshake failure and certificate mismatch are not interchangeable findings. A successful handshake also does not establish that the sender would refuse a future downgraded connection. Include controlled negative cases when authorised, especially before enabling a strict transport requirement.
Work through a coverage gap
In this synthetic inventory example, mx1.example.net has IPv4 and IPv6 routes and mx2.example.net is a backup. A sample observation covers only mx1's IPv4 address. The inventory must mark the IPv6 and backup routes untested rather than propagating success across all three. The observation is explicitly synthetic and carries no claim of a real connection.
Add a sender-side acceptance row for a supporting MTA using a valid enforcing policy, another with an empty cache, and a DANE-capable sender with validated TLSA. These rows remain pending until actual logs are captured. This makes the acceptance plan useful without presenting expected outcomes as measurements. It also lets an incident responder see whether the failed route was ever exercised.
Reconcile reports and operational evidence
References: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT reports can reveal failures seen by participating senders over a reporting period, complementing point-in-time probes. Their session counts are not unique-message counts and their coverage is not universal. A quiet reporting period does not prove all routes succeeded, and repeated retries can complicate business-impact estimates. RFC 8460 section 4.4.
Keep the raw result, timestamp, tool version or command, and the narrower conclusion you drew from it. Retest after certificate renewal, MX migration, DNSSEC changes and policy updates. The review package includes seven retained 7 November 2026 loopback transcripts, with peer-certificate bytes for the four sessions that reached certificate capture. They cover a local IPv4 Python client/server at generated ports with explicitly configured trust and policy inputs, not Internet SMTP, a DNSSEC validation chain, production MTA queues or full MTA-STS certificate-profile compliance. The historical sessions were inspected but not rerun here. The example Internet IPv4, IPv6 and backup paths remain untested; none inherits a local pass. The newly executed offline coverage model only checks that one synthetic observed route leaves the other listed routes untested. Capture the intended MTA and routing observations before claiming deployment assurance.