TLSRPT

In modern E-Mail communication, Opportunistic TLS is common. This means that TLS encryption for the transition of E-Mail is negotiated by MTAs on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement can be reached, mail is transferred unencrypted.

MTA-STS was introduced in RFC 8461. It's main purpose is to assure TLS connections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 states that MTA-STS is intended to be used along with TLSRPT (RFC 8460). It doesn't include the recommendation to send reports, but MTA-STS compliant MTAs should be able to receive and process TLSRPT reports at least.

TLSRPT is also used to monitor and troubleshoot DANE. Unfortunately, without a valid MTA-STS policy ("testing", "enforce" or "none"), most reporting organisations don't send reports at all.

Configuring TLSRPT

TLSRPT is configured with a DNS record on a specific subdomain of your organisational domain, which includes the connection protocol. A TLSRPT record for E-Mail connections looks like this:

$ host -t txt _smtp._tls.senderdomain.TLD
_smtp._tls.senderdomain.TLD descriptive text "v=TLSRPTv1; rua=mailto:tlsrpt@dmarc.example.com;"

Reports about successful and failed TLS connections is sent to the address in the rua-switch. TLSRPT reports provide information about:

• Volume / Reporting organisations
• TLS successes and failures
• Information about policies used (MTA-STS, TLSA, DANE, etc.)

TLS reports with InboxSys

This document from ECO explains in detail how to monitor DMARC reports with several open source tools. On request, InboxSys hosts a DMARC monitor consisting of Parsedmarc, Elasticsearch and a Kibana dashboard. The latest version of our hosted Parsedmarc package contains reporting monitors for DMARC and TLSRPT.

Useful links

• RFC 8460: TLSRPT RFC
• RFC 8461: MTA-STS RFC
• InboxSys DMARC Monitor
• wikipedia:Opportunistic_TLS