MTA-STS tells senders to require TLS. TLS-RPT — SMTP TLS Reporting — is the channel through which those senders tell you whether it worked. Without it you are enforcing a policy blind, with no way to know whether a legitimate correspondent is quietly failing to reach you. With it, the big providers who send you mail deliver a daily summary of every TLS negotiation they attempted, and that summary is what makes a safe rollout possible. This article covers the record you publish, the report you receive, and what to do about each result type you might find in it.
The record: _smtp._tls
You opt in to reporting by publishing a single TXT record at _smtp._tls.yourdomain:
_smtp._tls.yourdomain. IN TXT "v=TLSRPTv1; rua=mailto:tlsreports@yourdomain"
The v=TLSRPTv1 tag identifies the record version and must come first. The rua tag (reporting URI, aggregate) names where reports should be sent. A mailto: address is the usual choice; the standard also permits an https: endpoint for providers that POST reports to a collector. You can list more than one destination, comma-separated. Note that this record is entirely independent of your MTA-STS policy file — TLS-RPT reports on both MTA-STS and DANE outcomes, so it is worth publishing even before your policy is live, so that reporting is already flowing when you switch MTA-STS on.
The report: a daily JSON aggregate
A reporting sender collects the results of its delivery attempts to your domain over a 24-hour window and sends you one aggregate report, typically as a gzip-compressed JSON attachment on an email to your rua address. The top of the report is metadata: an organization-name identifying the sender, a date-range with a start and end timestamp, a contact-info address, and a unique report-id. It is a summary of counts, not a log of individual messages — no message content or recipient addresses are exposed.
The body is a policies array. Each entry describes one policy the sender applied to your domain and how deliveries against it fared. A single entry contains a policy object (its policy-type — sts for MTA-STS, tlsa for DANE, or no-policy-found — plus the policy strings and the MX host it applied to), a summary with total-successful-session-count and total-failure-session-count, and a failure-details array that is populated only when failures occurred.
Reading a report is therefore a two-step move: look at the summary counts to see the ratio of success to failure, then, if there are failures, drop into failure-details to see why. Each failure-detail object carries a result-type, the sending-mta-ip and receiving-mx-hostname involved, and a failed-session-count telling you how many attempts hit that specific problem.
Success looks like nothing
The happy case is a policy-type of sts, a healthy total-successful-session-count, a total-failure-session-count of zero, and an empty failure-details. That means the sender fetched your policy, matched the MX, validated the certificate, negotiated TLS, and delivered — exactly what you want before you move a policy from testing to enforce. A run of reports like this from your major correspondents is the green light described in the testing-to-enforce rollout.
The failure result types, and what each one means
When failures appear, the result-type tells you which layer broke. The ones you will most often see:
starttls-not-supported— the sender connected to your MX but the server did not offer STARTTLS, or the STARTTLS command failed. This usually points at an MX host with TLS misconfigured or disabled, or a backup MX run by a third party that never had TLS. Fix the host so it advertises STARTTLS; verify directly with STARTTLS Studio.certificate-expired— TLS was offered but the MX's certificate had passed its expiry date. The fix is renewal and, usually, a look at why automated renewal did not fire. This is the failure most likely to appear suddenly on a previously healthy domain.certificate-host-mismatch— the certificate presented does not name the MX hostname the sender was required to use, so the identity check fails. It typically means the certificate is issued for a different name than the one in yourmxlist, or the MX record and certificate have drifted apart.certificate-not-trusted— the certificate does not chain to a trusted public root; common with self-signed certificates or a missing intermediate in the chain.validation-failure— a catch-all for a TLS or policy validation problem that does not fit the more specific types above, such as a protocol-level negotiation failure. Use the accompanyingreceiving-mx-hostnameandsending-mta-ipto reproduce and narrow it down.sts-policy-fetch-errorand related policy types — the sender could not retrieve or parse your policy file (for MTA-STS) — for example themta-stshost was unreachable, served the wrong content type, or presented an invalid certificate for the policy host itself.
How to act on a report
Triage by impact. A failure type against a high-volume sender, or one that recurs across several days, is a real problem affecting real mail and should be fixed first. An isolated failure from a single obscure IP might be a transient network event or a misbehaving sender, and is worth noting but not panicking over. Correlate the receiving-mx-hostname in the failure with your own MX list: if failures cluster on one MX host, that host is your problem; if they are spread evenly, suspect something domain-wide such as the policy host or a certificate that covers all of them.
Crucially, while you are still in testing mode these failures cost you nothing — the mail was delivered anyway and the report is a warning, not an incident. That is the whole value of the sequence: TLS-RPT lets you find and fix starttls-not-supported or certificate-expired conditions on your own timetable, before enforce would have turned them into deferrals and bounces. Once you are enforcing, keep reading the reports — they remain your early-warning system for the next certificate that lapses or the next MX you add without updating the policy.
Where TLS-RPT fits
Publish _smtp._tls early, keep an eye on the aggregates, and treat any failure type attributable to your own configuration as a to-do. Combined with a policy you can check on the home page and the handshake-level view from STARTTLS Studio, it gives you a complete picture of inbound TLS health; DNS Studio connects it to the wider set of mail records you should be maintaining.