Fix Missing TLS-RPT Reporting Policy

What's happening

TLS-RPT, defined in RFC 8460, is the reporting half of MTA-STS — published as a TXT record at _smtp._tls. with rua= addresses where receivers send daily aggregate reports of TLS connection failures, downgrade attempts, and certificate validation problems.

Without TLS-RPT, you have no first-party signal that mail to your domain is encountering TLS problems. An expired certificate, a misconfigured cipher suite, or an active downgrade attack all produce silent delivery failures or in-transit cleartext exposure that you only learn about when customers complain.

Combined with MTA-STS, TLS-RPT closes the visibility gap. MTA-STS enforces TLS; TLS-RPT tells you who tried to deliver and what failed. Without both, you are flying blind on inbound transport security.

Why it matters

Silent TLS failures. Cert renewal misses, cipher mismatches, and policy-file errors all produce delivery failures or downgrade-then-cleartext on the receiver side. Without TLS-RPT, the first signal is a customer ticket days later.

Active attacks unobserved. Downgrade attempts and STARTTLS-stripping show up in TLS-RPT reports. Without the reports, an attacker can downgrade your inbound mail flow indefinitely and you have no telemetry to investigate.

Compliance and forensics gaps. Incident response after a suspected mail-interception event requires logs of TLS connections. TLS-RPT provides that record from receivers, complementing your own MTA logs.

Common causes

• TLS-RPT not yet on the operator's radar — newer and less-known than SPF/DKIM/DMARC.
• MTA-STS deployed but TLS-RPT skipped because TLS "seems to work".
• Reporting mailbox not set up; team unsure where reports should go.
• rua= cross-domain authorization missing (similar to DMARC cross-domain restrictions).
• Migration to a new domain copied MTA-STS but not TLS-RPT.

Detect this on your site

Run a quick scan with the Email Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Choose a reporting destination

   Use a dedicated mailbox like tls-rpt@example.com or a hosted reporting service. dmarcian, EasyDMARC, and Valimail all parse TLS-RPT reports alongside DMARC. Postmark DMARC Digest also supports TLS-RPT. Hosted is recommended unless you have engineering capacity to parse the JSON reports.

2. 2

   Publish the TLS-RPT TXT record

   Add a TXT record at _smtp._tls.example.com with value v=TLSRPTv1; rua=mailto:tls-rpt@example.com. Multiple destinations are allowed: rua=mailto:tls-rpt@example.com,mailto:rpt@example.dmarcian.com.

3. 3

   Handle cross-domain authorization

   If rua= points to a domain you do not own (e.g. dmarcian's domain), the receiving domain must publish authorization. Hosted services handle this automatically. Self-managed cross-domain reporting requires the recipient domain to publish an authorization TXT record per RFC 8460 Section 3.

4. 4

   Verify with dig

   Run dig +short TXT _smtp._tls.example.com and confirm the v=TLSRPTv1 record. Wait 24-48 hours for first reports — Google and Microsoft 365 typically begin sending within one day.

5. 5

   Set up parsing or use the hosted dashboard

   TLS-RPT reports are JSON, attached to email or POSTed to an HTTPS endpoint. Open-source parsers exist (parsedmarc supports TLS-RPT). Hosted services display dashboards with breakdowns by sending IP, MX, and failure type.

6. 6

   Establish a weekly review cadence

   Reports surface cert expiry, cipher mismatches, and downgrade attempts. Weekly review catches problems before they impact significant volume. Pair the review with the MTA-STS policy refresh so changes are coordinated.

Example

; TLS-RPT TXT record
_smtp._tls.example.com. 86400 IN TXT "v=TLSRPTv1; rua=mailto:tls-rpt@example.com"

; HTTPS endpoint variant (rare but allowed by RFC 8460)
_smtp._tls.example.com. 86400 IN TXT "v=TLSRPTv1; rua=https://reports.example.com/tls-rpt"

TLS-RPT TXT record for a self-managed mailbox or HTTPS endpoint.

Related fixes