🔒 OSH.co.za Domain Deliverability Checker

TLS-RPT (SMTP TLS Reporting, defined in RFC 8460) is a mechanism that lets receiving mail servers report back to senders when TLS encryption failed during email delivery. When a sending server tries to deliver email and encounters a TLS negotiation failure — for example because your MTA-STS policy could not be met — it generates an aggregate JSON report and sends it to the addresses listed in your TLS-RPT record. You publish the record as a DNS TXT entry at _smtp._tls.yourdomain.com containing a value like v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com. These reports help you detect delivery failures caused by TLS misconfigurations before they impact a significant volume of mail.

TLS-RPT aggregate reports are JSON files (delivered as gzip-compressed email attachments) that detail TLS connection attempts to your domain over a 24-hour window. Each report includes: the policy type that was applied (MTA-STS or DANE), the policy string, the total number of successful TLS sessions, and a breakdown of any failures by failure type (e.g. starttls-not-supported, certificate-expired, validation-failure). Reports also include the sending MTA's identity and the sending date range. By analysing these reports you can identify which sending servers are failing to establish encrypted connections and why, allowing you to fix TLS configuration issues proactively.

MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT are complementary standards designed to work together. MTA-STS enforces that sending mail servers must use valid TLS when connecting to your mail server — it publishes a policy file over HTTPS that specifies the required MX hostnames and the TLS enforcement mode (enforce, testing, or none). TLS-RPT provides the feedback loop: when a sender cannot satisfy your MTA-STS policy, it generates a report and sends it to your TLS-RPT reporting address. Without TLS-RPT, you would never know if your MTA-STS policy was causing deliveries to fail. Together, they give you both strong enforcement of encrypted transport and visibility into any issues. It is strongly recommended to deploy both simultaneously, starting with MTA-STS in testing mode while monitoring TLS-RPT reports before switching to enforce.

Reports are delivered to the addresses listed in the rua= field of your TLS-RPT record. You can specify one or more addresses, separated by commas. Two URI schemes are supported: mailto: (e.g. rua=mailto:tls-rpt@yourdomain.com) which causes reports to be emailed to that address as gzip-compressed JSON attachments, and https: (e.g. rua=https://reporting.example.com/v1/tlsrpt) which causes reports to be POSTed to an HTTPS endpoint. Many organisations use a dedicated mailbox or a third-party reporting service such as Postmark, Valimail, or dmarcian. Reports are sent daily, typically covering the previous UTC day. Make sure the receiving address can handle the volume of reports if you have many senders or a large mail infrastructure.