TLS-RPT (Transport Layer Security Reporting) is a mechanism defined in RFC 8460 that allows sending email servers to share statistics and details about potential TLS failures with recipient domain owners.

It works alongside MTA-STS and DANE to provide visibility into secure email delivery, helping domain owners understand when and why secure connections fail.

Key Benefits:

• Monitor TLS connection failures in real-time
• Identify certificate and configuration issues
• Improve email security posture
• Compliance with security standards
• Enhanced visibility into email delivery security

• Use multiple reporting endpoints for redundancy
• Monitor report volumes to ensure your endpoints can handle the load
• Set up proper authentication for HTTPS endpoints
• Consider using a dedicated subdomain for TLS reporting
• Regularly review failure reports to identify delivery issues
• Coordinate TLS-RPT deployment with MTA-STS implementation
• Test your reporting endpoints before publishing DNS records
• Keep DNS TTL reasonably low during initial deployment
• Document your TLS-RPT implementation for your team

DNS Record Details

TLS-RPT records must be published as TXT records at a specific subdomain:

Record Format

The basic TLS-RPT record format includes:

• v=TLSRPTv1 - Version identifier (required)
• rua= - Comma-separated list of reporting URIs (required)

Example Records

DNS Propagation

After publishing your TLS-RPT record, allow up to 48 hours for DNS propagation. You can verify the record using DNS lookup tools.

Official Documentation

• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - SMTP MTA Strict Transport Security

Testing Tools

• MX Toolbox - DNS Lookup
• DNS Checker
• TLS-RPT Validator

Educational Resources

• DMARC Wise - TLS-RPT Guide
• APNIC - Introducing SMTP TLS Reporting
• Mailmodo - TLS-RPT Guide
• GoDMARC - What is TLS-RPT