TLS-RPT RFC: SMTP TLS Reporting explained

What are the requirements?

The policy is published as a DNS TXT record

RFC 8460 distributes a TLS-RPT policy as a TXT record at _smtp._tls.. The record's version tag must be v=TLSRPTv1, and the policy requires one or more rua values that identify report destinations. The standard permits mailto and HTTPS report URIs.

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=https://reports.yourdomain.com/v1/tlsrpt"

These are illustrative only. Publish the real reporting address or HTTPS endpoint that your team controls.

RFC 8460 says parsers MUST accept syntactically valid records with semicolon-separated key and value pairs, and they SHALL ignore unknown fields. It also defines processing rules for multiple or invalid records. Do not use a generic TXT record at the domain apex as a substitute for the _smtp._tls owner name. For a focused explanation of the version tag, see what v=TLSRPTv1 means.

The report describes policy results, not every delivery outcome

The report schema is I-JSON. It includes report metadata, the policy applied, and aggregate session counts. RFC 8460 defines a successful session as one where the sending MTA negotiated a policy-compliant TLS connection. It also defines result types for failures such as DNS, STARTTLS, certificate, DANE, and MTA-STS policy problems.

A TLS-RPT report is evidence from one reporting sender's observed SMTP sessions. It is not a list of every message sent to your domain, a sender-authentication report, or proof that a particular recipient received a message.

Report transport has defined constraints

RFC 8460 says a report MAY be delivered by email. Email reports use multipart/report with report-type="tlsrpt" and carry the machine-readable report as application/tlsrpt+json or application/tlsrpt+gzip. A report sent by SMTP MUST have a valid DKIM signature from the reporting domain, and a recipient MUST ignore an SMTP-delivered report that lacks that signature.

The standard also supports HTTPS delivery. The receiving HTTPS server MUST return a successful response, typically HTTP 200 or 201, for a delivered report. A non-success response can be treated as a delivery failure and retried according to the sender's local policy.

These rules describe compliant report exchange. They do not require an operator to expose a public report endpoint if the selected rua is a mailbox address, and they do not establish that every sender will deliver reports on the same schedule.

When does the requirement take effect?

RFC 8460 was published in September 2018 as an IETF Standards Track document with Proposed Standard status. It replaced the Internet-Draft draft-ietf-uta-smtp-tlsrpt; the final RFC is the controlling specification.

There is no universal TLS-RPT enforcement date in RFC 8460. The RFC defines a protocol that domains and sending MTAs may implement. MTA-STS has its own policy behavior: RFC 8461 says that in testing mode, a sending MTA that also implements TLS-RPT sends a policy-application-failure report when the recipient domain also implements TLS-RPT, while mail may still be delivered as if no MTA-STS validation failure occurred.

How do I implement the requirement?

1. Identify the TLS-RPT policy domain

Start with the recipient domain that receives SMTP mail. If your delivery design routes mail through a locally configured smarthost, confirm whether that smarthost domain is the policy domain under RFC 8460.

Keep this decision separate from the visible From: domain. SMTP routing uses the envelope recipient and MX delivery path, while RFC 5322 defines the Internet Message Format used for message headers and body.

2. Choose a report destination your team can operate

Select a mailto address or HTTPS endpoint that can receive and retain aggregate reports. Limit access because reports can reveal receiving MX hostnames, sending-MTA IP addresses, policy details, and session-failure information.

For an email destination, make sure the receiving workflow can process the TLS-RPT report format and DKIM validation. For HTTPS, make sure the endpoint can accept the required report payload and return a successful HTTP response.

3. Publish the TXT record at the exact owner name

Create the TXT record under _smtp._tls for the policy domain, using v=TLSRPTv1 followed by the reporting URI. Follow the DNS provider's interface carefully, especially where it adds the zone suffix automatically.

Use Palisade's DNS lookup tool to inspect the publicly resolvable record after DNS propagation. A DNS lookup can show the published TXT response. It cannot prove that an MTA uses the record, that an HTTPS receiver accepts reports, or that a production SMTP session used TLS.

4. Pair reporting with the policy you want to observe

TLS-RPT has the most specific operational value when your domain also uses MTA-STS or DANE. MTA-STS communicates a receiving domain's TLS expectations; TLS-RPT gives compatible senders a defined way to report policy outcomes. Use the MTA-STS checker to inspect the public MTA-STS and TLS-RPT records together, then compare the result with your authoritative DNS configuration.

Do not move an MTA-STS policy to enforcement based only on a TLS-RPT DNS record. DNS publication does not establish that your MX hosts, certificates, and production SMTP routes satisfy the policy.

How do I validate compliance?

Validate the DNS layer first. Query the authoritative DNS provider and at least one public resolver for _smtp._tls.yourdomain.com and confirm that the returned TXT value has v=TLSRPTv1 and the intended rua destination.

Validate the receiving layer next. For an HTTPS rua, confirm that the endpoint accepts a conforming report and returns a successful HTTP response. For a mailto destination, confirm that the receiving workflow accepts and validates a DKIM-signed TLS-RPT message. Retain only the report data that operators need for investigation.

Then validate the transport-policy layer with evidence from an actual sending MTA that supports TLS-RPT. Check whether its aggregate report identifies the expected policy domain, MX host, policy type, time range, and result counts. A report with successful sessions is evidence about the reporting MTA's observed sessions only.

Finally, inspect the linked MTA-STS or DANE configuration and the production SMTP path. A TLS-RPT record does not establish that a sender fetched MTA-STS, performed DANE validation, negotiated TLS on every route, or delivered a message to a mailbox. The Infrastructure learning hub has related guidance for transport and DNS controls.

Review the transport policy behind TLS-RPT

TLS-RPT tells compatible senders where to submit aggregate observations. The next operational question is which transport policy, MX identity, and TLS behavior those observations should be compared against.

Read the email transport security guide

That guide can help you assess the transport-security design around a TLS-RPT record. It does not prove that a particular sending MTA will publish a report or guarantee delivery for a future SMTP session.