TLS-RPT, short for SMTP TLS Reporting, is a DNS-based reporting standard for mail transport security. It tells other mail systems where to send reports when they cannot deliver mail using the TLS security policy your domain publishes through MTA-STS or DANE. TLS-RPT does not encrypt mail by itself; it provides visibility into whether a transport-security policy is working in the real world.
Why transport reporting matters
Email authentication answers whether a message is authorized to use a domain. Transport security addresses how a message travels from the sender to your receiving mail system. Without reporting, a TLS policy failure can be invisible until a sender delays mail or a customer reports a delivery problem. TLS-RPT creates a way to collect evidence about those failures and investigate the underlying infrastructure.
The relationship with MTA-STS
MTA-STS lets a domain publish a policy asking supporting senders to use TLS and validate the expected MX hosts when delivering inbound mail. TLS-RPT is the companion reporting channel. If a sender cannot follow the policy because an MX host, certificate, DNS record, or route does not match, it may send a report to the address you specify. Read MTA-STS explained before deploying either control.
Where the record goes
A TLS-RPT record is a DNS TXT value at _smtp._tls.yourdomain.com. It begins with v=TLSRPTv1 and includes one or more reporting destinations, often an email address using rua=mailto:. Use the exact syntax in current standards and provider documentation. Publish one intentional record, verify it resolves publicly, and do not treat a similar-looking DMARC reporting tag as interchangeable.
Choose a reporting destination carefully
Reports can be XML data and may be sent by systems you do not control. Use a dedicated mailbox or service with monitored access, retention, and a named owner. An abandoned reporting address creates false confidence: the record exists, but nobody learns that a sender has a persistent delivery-security problem. Protect access to the mailbox because reports may reveal useful operational information about mail routes.
What to look for in a report
Review the reporting organization, date range, destination domain, policy type, affected MX host, and failure description. A one-off issue may be transient; repeated reports involving a known sender or destination deserve investigation. Compare the timing with recent changes to MX records, certificate renewal, DNS hosting, or a mailbox migration. Do not immediately loosen a security policy without confirming what actually changed.
Common causes of problems
Typical causes include an MTA-STS policy that lists an old MX hostname, a certificate that no longer matches the receiving host, a policy file that is unavailable over HTTPS, or a mail-provider migration that changed the real delivery route. These are infrastructure alignment problems. The best fix is usually to update the policy or underlying infrastructure so they agree, then verify with fresh delivery tests.
Plan a safe rollout
- Stabilize SPF, DKIM, and DMARC first; they solve a different but more immediate trust problem.
- Document current MX hosts, DNS ownership, policy host, and certificate owner.
- Publish the reporting record and confirm its public DNS value.
- Deploy MTA-STS in a testing mode where appropriate.
- Monitor reports and normal inbound delivery before enforcing changes.
Make only one infrastructure change at a time during rollout. This preserves evidence and makes a rollback possible if an unexpected delivery issue appears.
Keep ownership after launch
Review TLS-RPT after any MX, certificate, DNS, or mail-provider change. Add it to the same domain-health review that covers expiry, website certificates, and email authentication. The value is not in publishing another DNS record; it is in having someone see, understand, and respond to meaningful transport failures.
Run Beacon’s free domain check to review the SPF, DKIM, and DMARC foundation alongside your transport-security controls.
For the related transport policy, review MTA-STS explained and the domain-health checklist.