# TLS-RPT RFC: SMTP TLS Reporting explained > TLS-RPT RFC 8460 defines SMTP TLS Reporting, its DNS policy record, report endpoints, report format, and practical validation checks for recipient domains. TLS-RPT is defined by [RFC 8460, SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460), an IETF Proposed Standard published in September 2018. It lets a recipient domain publish where compatible sending MTAs should send aggregate data about SMTP TLS and transport-policy failures. It is relevant to domains using MTA-STS or DANE, and it reports observed sessions rather than enforcing TLS on its own. ## Quick takeaways - RFC 8460 is the controlling RFC for SMTP TLS Reporting, commonly called TLS-RPT. - A TLS-RPT policy is a DNS TXT record below `_smtp._tls` for the policy domain. - The record starts with `v=TLSRPTv1` and includes at least one `rua` reporting URI. - TLS-RPT can report successful policy-compliant TLS sessions and defined failure types. - TLS-RPT complements MTA-STS or DANE. It does not require a sending MTA to use either policy. - A published DNS record does not prove that sending MTAs will send reports or that mail will be delivered. ## Who is affected? TLS-RPT applies to recipient domains that want compatible sending MTAs to send aggregate reports about SMTP TLS sessions and transport-policy failures. [RFC 8460](https://datatracker.ietf.org/doc/html/rfc8460) defines the policy domain as the domain against which a TLS-RPT, MTA-STS, or DANE policy is defined. For TLS-RPT and MTA-STS, that is usually the SMTP envelope recipient domain defined by [RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321), though a locally configured smarthost can change the relevant domain. The recipient-domain operator publishes the reporting policy and operates the destination named in `rua`. A sending MTA decides whether it supports TLS-RPT and, when it does, generates the report from its own delivery attempts. RFC 8460 does not make every sending MTA report, and it does not require a mailbox provider to use TLS-RPT. TLS-RPT is separate from the TLS protocol itself. [SMTP STARTTLS is specified in RFC 3207](https://datatracker.ietf.org/doc/html/rfc3207); TLS-RPT defines reporting around SMTP TLS and applicable MTA-STS or DANE policy outcomes. For the broader transport-security context, see [email transport security](/learning/email-transport-security). ## 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. ```text _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. ![TLS-RPT DNS policy anatomy showing the policy owner name, version tag, and aggregate-report URI](/images/editorial/tls-rpt-rfc/tls-rpt-rfc-record-anatomy.webp "1200x466") *Source: Palisade.* 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](/learning/glossary/tls-rpt-v-tlsrptv1). ### 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](https://datatracker.ietf.org/doc/html/rfc8461) 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](https://datatracker.ietf.org/doc/html/rfc5322) 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](/tools/dns-lookup) 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](/tools/mta-sts) 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](/learning/infrastructure) 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](/learning/email-transport-security) 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. ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://datatracker.ietf.org/doc/html/rfc8460) - [RFC 8461: SMTP MTA Strict Transport Security](https://datatracker.ietf.org/doc/html/rfc8461) - [RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc3207) - [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) - [RFC 5322: Internet Message Format](https://datatracker.ietf.org/doc/html/rfc5322) ## Frequently asked questions ### What is TLS RPT? TLS-RPT is SMTP TLS Reporting, defined by RFC 8460. A recipient domain publishes a DNS policy that names report destinations, and compatible sending MTAs can send aggregate information about SMTP TLS and applicable MTA-STS or DANE policy outcomes. ### Which RFC defines TLS? No single RFC defines every version and use of TLS. RFC 8460 defines TLS-RPT for SMTP reporting, while RFC 3207 defines the SMTP STARTTLS extension. TLS itself has separate protocol specifications. ### What is RFC 5321 and RFC 5322? RFC 5321 defines SMTP, including the envelope and relay behavior used to transfer email between mail systems. RFC 5322 defines the Internet Message Format, including message headers and body. TLS-RPT policy-domain decisions are normally tied to SMTP routing, not solely to visible RFC 5322 headers. ### How do I configure TLS RPT? Publish a TXT record at `_smtp._tls.` with `v=TLSRPTv1` and at least one `rua` destination that your team operates. Then verify the record through authoritative and public DNS, test the report receiver, and review reports from compatible sending MTAs. ### Does TLS-RPT enforce SMTP TLS? No. TLS-RPT reports observed TLS and transport-policy outcomes. MTA-STS or DANE defines the relevant transport policy, while the sending MTA determines whether it supports TLS-RPT and sends a report.