TLS-RPT

TLS-RPT (SMTP TLS Reporting) asks the mail servers that send to you to report back whenever they have trouble establishing a secure, encrypted (TLS) connection to your domain. It enforces nothing and changes nothing about how your mail flows — it’s a feedback channel. Without it, TLS delivery problems happen silently: you never find out that messages are arriving over a downgraded connection, or failing to arrive at all.

TLS-RPT is the visibility half of a pair. MTA-STS tells sending servers to require TLS when they deliver to you; TLS-RPT tells you when that requirement is being violated or failing. You can publish TLS-RPT on its own — it’s useful anywhere — but it’s most powerful alongside MTA-STS, where it’s the only way to see whether your policy is actually holding.

What you actually publish

Just one thing: a single DNS TXT record at _smtp._tls.yourdomain.com. That’s the entire setup. There’s no policy file to host, no MX list to maintain, and no enforcement mode to stage — everything MTA-STS needs, TLS-RPT doesn’t. The record names a destination where reports should be sent, and that’s it.

Worked example

Say your domain is example.com. Here’s the complete, copy-pasteable record:

Field	Value
Type	TXT
Name / Host	_smtp._tls.example.com
Value	v=TLSRPTv1; rua=mailto:[email protected]

Two tags, and that’s all there is to it:

• v=TLSRPTv1 — the version tag. The record must begin with exactly this; if it doesn’t, sending servers don’t recognize it and skip it entirely.
• rua= — the reporting address: where the daily reports get sent. It’s either a mailto: address or an https: endpoint that accepts report uploads.

If you’d rather receive reports at a web endpoint than a mailbox, use the https: form instead:

v=TLSRPTv1; rua=https://tls-reports.example.com/api/tlsrpt

You can also list more than one destination, separated by commas — for example a mailbox and an endpoint.

One record, and it must point somewhere

The checker flags three things, all easy to avoid:

• Publish exactly one TLS-RPT record. RFC 8460 forbids more than one at _smtp._tls. — if a second record appears, sending servers ignore all of them and reporting silently stops.
• The value must start with v=TLSRPTv1. That prefix is how servers recognize the record; without it, the record is invisible.
• It must carry a rua= destination, and that destination must be a mailto: address or an https: endpoint. A record with no rua=, or a malformed one, collects nothing — the reports have nowhere to go.

Where the reports go

The rua= destination is the one real decision. Point it at something you’ll actually read:

• A mailbox you control — e.g. [email protected]. The simplest option; reports arrive as email attachments.
• An HTTPS endpoint — if you have a service that ingests reports programmatically.

The record itself is an ordinary TXT entry at your normal DNS host — every provider supports it, and it costs nothing to add. There’s no separate subdomain, certificate, or file to serve (the part MTA-STS needs, TLS-RPT skips).

Safe to publish today

Unlike MTA-STS — where a wrong mx: entry in enforce mode can bounce real mail — TLS-RPT can’t break anything. It doesn’t change how mail is routed or whether it’s accepted; it only requests reports. There’s no testing period to sit through and no enforcement step to stage. Pick a destination you’ll read, publish the record, and you’re finished — the worst case is simply that no reports show up.

What you’ll actually get

Once the record is live, the big mail providers that support TLS reporting — Google, Microsoft, Yahoo, and others — send a daily aggregate report: a JSON summary of how many connections to your domain used TLS successfully, how many failed, and why.

These arrive as machine-readable JSON, one per reporting provider per day. For a healthy domain the summary is reassuringly boring — near-100% success, nothing to do. Its value shows up on the bad day: a TLS-RPT report is usually the first place a downgrade attempt, an expired certificate, or a broken MTA-STS policy becomes visible — while mail is still mostly flowing, and before the problem turns into an outage.

Verify it’s live

After you publish, confirm the record resolves, starts with v=TLSRPTv1, and carries a valid rua= destination — and that there’s only one of it. The free checker runs all of that and tells you in plain language what’s set and what’s missing:

Verify yours → Run the free TLS-RPT checker against your domain.

Where TLS-RPT sits in the bigger picture

TLS-RPT is pure visibility — it reports on the encrypted transport of inbound mail and changes nothing on its own. It pairs naturally with MTA-STS, the half that actually requires TLS; together they give you enforcement plus the feedback to know it’s working. Both are separate from SPF, DKIM, and DMARC, which authenticate who sent a message rather than protecting the connection it travels over.