All articles
What is TLS-RPT and why SMTP TLS reporting matters
Security Tips

What is TLS-RPT and why SMTP TLS reporting matters

TLS-RPT is the DNS record that asks sending servers to report when they can't deliver mail to you securely. It turns silent TLS failures into data you can act on.

You can require TLS for inbound mail with MTA-STS or DANE - but how do you know it's actually working? TLS-RPT is the feedback channel. It asks other mail servers to send you a report whenever a secure delivery to your domain fails, so problems surface as data instead of vanishing silently. This guide explains what TLS-RPT is, how it works, where it breaks, and how SecRift checks yours.

What is TLS-RPT?

TLS-RPT stands for SMTP TLS Reporting. It is a DNS TXT record, published at _smtp._tls.example.com, that tells sending mail servers where to send daily reports about their TLS connections to your domain.

A typical record looks like this:

v=TLSRPTv1; rua=mailto:[email protected]

That says: if you're a sending server, send your aggregate TLS reports to this address. The reports summarize successful and failed secure deliveries, including why a TLS handshake or policy check failed.

TLS-RPT doesn't enforce anything on its own. Its job is visibility - the missing diagnostic layer for the security policies you publish elsewhere.

How TLS-RPT works

TLS-RPT plugs into the transport security you already publish:

  • A sending server attempts a secure delivery to your domain, applying any MTA-STS or DANE policy you publish.
  • If the connection or policy check fails - a certificate mismatch, a missing STARTTLS, a broken MTA-STS policy - the sender records it.
  • Once a day, the sender compiles the successes and failures into an aggregate report and sends it to the address in your rua tag.

The rua tag accepts a mailto: address or an https: endpoint that receives reports. Each report is structured data - usually JSON - that report-processing tools can parse into a clear picture of who is delivering to you securely and who is hitting errors.

The result is an early-warning system. A misconfiguration that would otherwise cause silent delivery failures shows up in the next day's reports.

Why TLS-RPT matters

Transport security has a quiet failure mode. When a sending server can't establish a policy-compliant TLS connection, it usually just defers or downgrades the message - and you never hear about it. A broken MTA-STS policy file or an expired certificate can quietly degrade mail security for days.

TLS-RPT removes the silence. Instead of discovering a problem when a customer complains about missing mail, you see failure reports the day after they start. It is the difference between operating your TLS policies blind and operating them with a dashboard.

Common TLS-RPT mistakes

  • No record at all. The most common state - you enforce TLS but collect no feedback, so failures stay invisible.
  • Missing or empty rua. A record with no valid reporting destination collects nothing.
  • Bad syntax. A malformed record - wrong version tag or broken rua - is ignored by senders.
  • Unmonitored destination. Reports arrive but no one parses them, which is no better than not collecting them.
  • Treating it as enforcement. TLS-RPT reports problems - it never blocks insecure delivery. It complements MTA-STS and DANE rather than replacing them.

How SecRift checks TLS-RPT

SecRift reads your TLS-RPT record from DNS and breaks the result into three findings:

  • Record publication - confirms your domain publishes a TLS-RPT TXT record at _smtp._tls.
  • Syntax - validates the record's version tag and structure so sending servers will honor it.
  • rua quality - checks that the rua destination is present and well-formed, so reports actually have somewhere to go.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix - for example, adding a valid rua mailto URI. SecRift only reads what you publish in DNS, so the result matches what a reporting sender would see.

TLS-RPT is the reporting half of inbound mail security. Pair it with MTA-STS to enforce TLS and then watch for failures with the reports TLS-RPT collects.

Run a free scan on any domain at secrift.com and see your TLS-RPT posture in seconds.