Definition
TLS-RPT, or SMTP TLS Reporting, is a standard (RFC 8460) that lets a domain owner publish a policy requesting reports about the TLS security of inbound email connections. When a sending server connects to the domain's mail server, the receiving side generates a report describing whether TLS was used successfully, failed, or was downgraded. These reports reveal configuration mistakes and potential interception attempts on the path to the domain.
How It Works
A domain owner publishes a DNS record that advertises the policy and where reports should be sent:
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
When another server delivers mail to example.com, the receiving infrastructure records the TLS outcome of that connection and, periodically, sends a JSON report to the address in the rua= tag. The report includes details such as:
- Whether the connection used TLS at all.
- The certificate and whether it validated correctly.
- Whether encryption was downgraded from what was expected.
- The sending server and time of the connection.
TLS-RPT is often paired with MTA-STS, a related standard that actually enforces TLS. TLS-RPT provides the visibility, while MTA-STS provides the enforcement.
Why It Matters
Email encryption in transit has historically been opportunistic: servers use TLS when both sides support it, but fall back to plain text silently. TLS-RPT closes that visibility gap by telling the domain owner when encryption is missing or failing. That matters for two reasons:
- A domain can detect and fix misconfigured certificates that prevent TLS.
- Repeated failures from a particular path can indicate an active downgrade attack, in which an attacker forces a plain-text connection to read the mail.
For email security-conscious organisations, TLS-RPT is a low-cost addition that complements DMARC reporting. DMARC reports on authentication, while TLS-RPT reports on transport encryption.
Example
A healthcare provider publishes a TLS-RPT policy. Within a week, reports show that connections from several small senders are arriving without TLS because of a certificate mismatch on the provider's server. The team fixes the certificate and later confirms through reports that inbound connections are now encrypted.
Was this useful?
Related Glossary Terms
Apple App Password (Email)
An Apple app password is a generated, app-specific password used to sign into an email account through clients that do not support two-factor authentication.
Email Authentication Protocols
Email authentication protocols are technical standards that verify the identity of an email sender, helping mailbox providers distinguish legitimate mail from spam and phishing.
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Email Deliverability
Email deliverability is the ability to land in the recipient's inbox rather than the spam folder. It depends on sender reputation, authentication, list quality, and content practices.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is an email authentication method that uses digital signatures to verify that an email was not tampered with during transit and comes from a authorised domain.
DMARC Aggregate Report
A DMARC aggregate report is a machine-readable XML summary that receiving mail servers send to domain owners daily to show authentication results for their email traffic.
Frequently Asked Questions
TLS-RPT requests reports about TLS outcomes, while MTA-STS publishes a policy that requires senders to use TLS and validates certificates. Together they provide enforcement plus visibility for inbound email encryption.
TLS-RPT governs reporting for inbound connections to your domain, not the mail you send. Outbound TLS behaviour is reported through the receiving domain's TLS-RPT or MTA-STS policy instead.
Publish a TXT record at `smtp.tls.
No. TLS-RPT is a security and visibility measure, not a delivery requirement. It helps a domain monitor its own inbound encryption rather than directly improving its outbound deliverability.