SMTP TLS Reporting: learning when senders cannot connect securely

What TLS-RPT does

TLS Reporting lets a receiving domain ask sending servers for daily summaries of TLS connection outcomes to its MX hosts, including successful sessions and failures such as expired certificates, name mismatches, STARTTLS not offered, or MTA-STS policy fetch errors. It is the feedback loop that makes MTA-STS and DANE safe to enforce.

_smtp._tls.example.org.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.org"

Reading a report

Reports are JSON, often gzip-compressed, with one entry per policy containing a summary of successful and failed session counts and failure details grouped by result type and sending or receiving host.

jq '.policies[] | {policy: .policy["policy-type"], ok: .summary["total-successful-session-count"], fail: .summary["total-failure-session-count"], details: [."failure-details"[]? | {(."result-type"): ."failed-session-count"}]}' report.json

Lab: interpret a failure

Publish the record for a domain you manage, or use a sample report from the RFC 8460 examples. Run the jq query above and identify each failure type. For a certificate-expired result, check the MX certificate with openssl and note its expiry; for a policy fetch error, curl the MTA-STS policy URL and confirm its certificate is valid.

• certificate-expired: renew the MX certificate
• certificate-host-mismatch: fix the name on the certificate
• starttls-not-supported: enable TLS on the MX
• sts-policy-fetch-error: fix the policy web host

Operating it

Route reports to a mailbox your mail team monitors or into a parser that alerts on any failure count above zero. Watch closely after certificate renewals and MX changes, which are the most common causes of failures.