NuStart Email Trust Series — Post 7 of 10

TLS-RPT is part of the Email deliverability acronym soup—SPF, DKIM, DMARC, TLS—and most businesses don’t have time to become part-time email engineers. In this series, I translate the geeky jargon into plain-English concepts and simple actions. You run the organization; I’ll do the nerding.

What is TLS-RPT?

TLS-RPT stands for SMTP TLS Reporting.

It’s a simple standard that lets your domain receive reports when other mail servers have trouble delivering email to you securely using TLS.

If MTA-STS is the “rule” (use encrypted delivery, deliver only to approved servers), TLS-RPT is the “dashboard” that tells you when something goes wrong.

For nonprofits and small businesses, that’s valuable because email problems are often invisible until someone says:

“Did you get my email?”
“We sent the contract…”
“The donor never received the receipt…”

TLS-RPT helps you catch those issues earlier.

What TLS-RPT does (and doesn’t) do

TLS-RPT does:

report TLS negotiation failures (can’t establish encryption)
report policy failures (MTA-STS/DANE-related issues, where supported)
help you spot misconfigurations, expired certificates, or routing changes

TLS-RPT does not:

stop spoofing (that’s DMARC)
fix spam placement by itself
guarantee every sender will report (not all senders support TLS-RPT)

Think of it as monitoring and visibility—not enforcement.

How TLS-RPT works (in plain English)

You publish a DNS TXT record at:

_smtp._tls.yourdomain.com

That record tells reporting mail systems where to send JSON-formatted reports, typically either:

an email address (mailto:), or
a web endpoint (https:)

Example (mailto):

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

Example (HTTPS endpoint):

v=TLSRPTv1; rua=https://example.com/tlsrpt

Then, participating senders will periodically send you reports when they detect issues delivering to your domain over TLS.

Why TLS-RPT is a great match for MTA-STS

MTA-STS helps protect secure inbound delivery, but without reporting you can still be “flying blind.”

TLS-RPT gives you:

early warning that something is breaking
evidence for troubleshooting (which senders, which errors, how often)
peace of mind when you move from testing to enforce

For organizations that rely on inbound email (donations, grant comms, partner outreach), visibility matters.

Step-by-step: set up TLS-RPT (the easy way)

Step 1: Decide where reports should go

You have two realistic choices:

Option A: A dedicated mailbox (simplest)

[email protected] or [email protected]

Pros: easy to set up.
Cons: reports are JSON and can be noisy; you still need a way to interpret them.

Option B: A reporting/monitoring service or endpoint
Pros: readable dashboards and alerting.
Cons: may cost money or require setup.

For most small orgs, start with a mailbox, then upgrade later if needed.

Step 2: Publish the DNS record

Create a TXT record:

Name/Host: _smtp._tls
Value: v=TLSRPTv1; rua=mailto:[email protected]
TTL: standard/default is fine

Step 3: Wait and monitor

Reports typically arrive periodically (often daily) depending on sender behavior. Not every sender supports reporting, so volume varies.

Reading TLS-RPT reports (without becoming a mail engineer)

TLS-RPT reports are usually JSON attachments. The “human” translation you care about is:

Which sending organization attempted delivery?
Did they fail TLS negotiation?
Did they fail MTA-STS policy checks?
How many attempts failed vs succeeded?

Common failure causes include:

wrong MX hostnames (policy mismatch)
TLS certificate issues on your inbound mail provider (rare with big providers)
temporary network routing or handshake errors
misconfigured policy file or unreachable MTA-STS policy host
changes during a migration (MX moved, but policy not updated)

If you’re using Google Workspace or Microsoft 365 for inbound mail, true TLS failures are uncommon—but the reports are still useful during changes and migrations.

Managed Hosting Reality Check (why TLS-RPT is friendly)

TLS-RPT is easier than MTA-STS for many managed hosting users because it’s only DNS. No website files, no subdomains required. You publish the record and you’re done.

That makes it a great “monitoring layer” even if you’re still working toward an MTA-STS policy host.

TLS-RPT best practices

Use a dedicated mailbox so reports don’t pollute your main inbox.
Keep the record stable; don’t change it often.
Pair it with MTA-STS for the best results.
Review reports during any email provider migration, DNS change, or major infrastructure shift.

Quick TLS-RPT checklist

TXT record exists at _smtp._tls.yourdomain.com
rua= points to a monitored mailbox or endpoint
You’ve confirmed inbound mail provider and MX records are correct
You review reports during migrations/changes
You’re ready to act if failures spike

TLS-RPT FAQs

Do I need TLS-RPT if I already have DMARC reports?

They cover different things. DMARC reports are about spoofing and authentication results. TLS-RPT is about encrypted delivery failures (transport security).

Will TLS-RPT fix delivery problems automatically?

No—TLS-RPT is reporting. It tells you what’s failing so you can fix it.

Why aren’t I receiving any TLS-RPT reports?

Not all sending systems support TLS-RPT. Also, if there are no TLS issues, there may be nothing to report.

Can TLS-RPT generate a lot of noise?

It can, depending on your volume and who emails you. That’s why a dedicated mailbox (or reporting service) is helpful.

Is it safe to use a mailbox for reports?

Yes, but expect JSON attachments. If you prefer something readable, use a reporting service or an endpoint that parses them.

Does TLS-RPT require MTA-STS?

No. You can publish TLS-RPT on its own. It becomes more valuable when paired with MTA-STS because you’ll see policy-related issues

Does TLS-RPT affect deliverability?

Not directly. It’s monitoring. The benefit is faster troubleshooting and fewer “mystery” delivery problems.

What should I do if I see failures?

First confirm the basics: MX records, MTA-STS policy reachability (if used), and whether failures correlate with a recent change. Then address the specific error type (certificate, policy mismatch, connectivity).

Want NuStart to handle this for you?
If you’d rather not wrestle with DNS records, alignment, and testing, NuStart can audit your current setup and implement a clean, reliable Email Trust configuration end-to-end. Request an Email Trust Audit today to get started.

Up next
Next: Post 8 — Reverse DNS & FCrDNS: Why mail servers must “match” to be trusted

TLS-RPT – Getting alerts when encrypted delivery fails