MTA-STS, TLS-RPT and DANE: mail transport security with Postfix 3.10
Postfix 3.10 adds TLS-RPT reporting for DANE and MTA-STS. What the three mechanisms do, how to enable reporting, and what the implementation does not cover.
By the Maborak engineering team · · 4 min read
SPF, DKIM and DMARC describe whether a message is authorised. They say nothing about whether the SMTP connection that carried it was encrypted or authenticated. MTA-STS, DANE and TLS-RPT cover that transport layer. Postfix 3.10 added the missing piece for operators: built-in TLS-RPT reporting.
Checked 29 October 2026. The Postfix behaviour and configuration below come from the Postfix 3.10.0 announcement and the TLSRPT howto. This is an operational guide, not a claim that every receiver or sender supports these mechanisms.
The three mechanisms
| Mechanism | Standard | What it does | Where it lives |
|---|---|---|---|
| MTA-STS | RFC 8461 | Requires TLS to the domain’s MX hosts and validates their certificates | _mta-sts TXT record plus an HTTPS policy at https://mta-sts.<domain>/.well-known/mta-sts.txt |
| DANE | RFC 7672 | Binds the MX certificate to DNSSEC-signed TLSA records | TLSA records, valid only under DNSSEC |
| TLS-RPT | RFC 8460 | Asks a receiving domain for daily summaries of successful and failed TLS handshakes to its MX hosts | _smtp._tls.<domain> TXT record |
They are complementary. MTA-STS works without DNSSEC; DANE requires it. TLS-RPT is observability for either: a domain publishes a reporting address and receiving MTAs send summaries. Without it, a sender learns about a broken certificate or a downgraded connection only from delivery failures.
What Postfix 3.10 adds
The 3.10.0 announcement adds TLS-RPT support:
- The SMTP client records a success or failure event for each TLS handshake and passes it to an in-process TLS-RPT library.
- A local collector, fetcher and report generator turn those events into daily summaries. The library and reporter are maintained by sys4 as libtlsrpt and tlsrpt-reporter.
- It supports DANE directly and MTA-STS through an
smtp_tls_policy_mapsplugin. Examples arepostfix-tlspolandpostfix-mta-sts-resolver, both of which emit the extra attributes Postfix needs for TLS-RPT.
Two operational changes are easy to miss:
- Postfix 3.10 needs a reload after upgrade. The release changes the delivery-agent protocol. If you skip
postfix reload(or stop and start), delivery agents logunexpected attribute smtputf8 .... - TLS-RPT support is a build-time option. It is not necessarily compiled into a vendor package. A source build uses
-DUSE_TLSRPTand linkslibtlsrpt; check the package before assuming the feature exists.
Turning it on
# main.cf
smtp_tlsrpt_enable = yes
smtp_tlsrpt_socket_name = run/tlsrpt/tlsrpt.sockA relative socket name is resolved under the Postfix queue directory and works whether or not chroot is enabled. The collector still needs the absolute path. Do not put the socket under private or public; only Postfix programs should create sockets there.
To receive reports for your own domain, publish:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"An https: destination is also allowed. The reporter, not Postfix alone, performs the daily generation and delivery.
Sending reports when TLS policy is strict
RFC 8460 says an MTA must not enforce TLS security when sending failure reports. Postfix 3.10 implements the RFC 8689 TLS-Required: no header for this: a report message carrying it is limited to smtp_tls_security_level = may, so it can be delivered even when the preferred policy cannot be enforced. Older outbound MTAs lack the header; the howto documents a dedicated transport that relaxes the security level for the report sender instead.
What TLS-RPT does not cover
The Postfix implementation reports TLS handshake success or failure. It does not report failure to connect, or connections that break before or after the handshake. It reports at most one final status per SMTP connection, so it will not report a recoverable failure and then a success on the same connection.
TLS-RPT is also not real-time. The howto notes that a failure takes on average around 12 hours to appear in a summary. Use it to catch trends and misconfiguration, not as a live paging signal.
Verification
Publish and check the records, then watch the mail log for the client’s own status lines:
dig +short TXT _smtp._tls.example.com
dig +short TXT _mta-sts.example.com
dig +short TLSA _25._tcp.mail.example.comTLSRPT: status=failure, domain=example.org, receiving_mx=mail.org[192.0.2.1],
failure_type=validation_failure, failure_reason=self-signed_certificateRun one receiver at a time with MTA-STS in testing mode before moving to enforce, and compare TLS-RPT summaries before and after. The goal is to find the MX host whose certificate does not match before a sender enforces the policy against it.
The primary references are the Postfix 3.10.0 announcement and the Postfix TLSRPT howto, with the standards in RFC 8460 (TLS-RPT), RFC 8461 (MTA-STS), RFC 7672 (DANE) and RFC 8689 (TLS-Required).
