Small DNS record, big visibility
Reports from servers that send you mail
Failures broken down by cause and sender
When encrypted delivery breaks, nothing tells you
Encryption controls like MTA-STS are powerful, but they have a blind spot. When they work, mail simply arrives. When they break (an expired certificate, a misconfigured server, a policy that no longer matches your real mail setup) a sending server may refuse to deliver insecurely, and the message just doesn’t arrive. There is often no bounce on your desk and no error to chase. The failure happens on someone else’s server, out of your sight.
TLS-RPT (SMTP TLS Reporting) closes that blind spot. It’s a small DNS record that politely asks the mail servers sending to you: if you ever fail to set up a secure, encrypted connection to my domain, please tell me about it. It turns silent, invisible delivery problems into something you can actually see and fix.
Why this matters, whoever you are
- It’s the early-warning system for MTA-STS: without it, TLS failures are invisible.
- Running your own domains? You find out a problem exists while it’s still small, not after weeks of lost mail.
- Managing clients? You catch an encryption problem on a client’s domain before they ever notice replies have stopped.
How it works: a request for feedback
TLS-RPT is just one DNS record. It doesn’t protect anything by itself; it asks for reports. You publish a record naming where the reports should be sent, and participating mail servers compile a daily summary of how their encrypted connections to you went, including anything that failed, and send it to that address.
The record, and what comes back
The record lives at _smtp._tls.yourdomain.com and names a destination for the reports:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
Each day, a sending server that supports TLS-RPT sends a structured summary covering how many connections succeeded, how many failed, and crucially why they failed: for example a certificate that didn’t validate, a connection that couldn’t be encrypted at all, or a policy mismatch. That “why” is what makes the difference between knowing something is wrong and knowing how to fix it.
What a report tells you
- Which sending source had trouble reaching you securely
- How many connections succeeded versus failed
- The failure type: certificate, policy, or connection problem
- The receiving host the failures were aimed at
- The window of time the problem occurred in
The catch: the reports are raw and easy to ignore
Publishing the record is the easy part. The reports themselves arrive as machine-readable files from dozens of different senders, every day, whether anything is wrong or not. Point them at an ordinary mailbox and they pile up unread, which means the one report that signals a real problem is buried among hundreds that simply confirm everything is fine.
The common failure mode is publishing TLS-RPT, feeling protected, and never actually reading a single report. The record only earns its keep when something is reading the reports, separating real failures from noise, and telling you what changed.
Where it goes wrong
- Reports pointed at a mailbox nobody reads
- Raw report files that are unreadable without tooling
- Real failures lost in a flood of “all good” reports
- TLS-RPT published but MTA-STS never enforced, so there’s little to report on
How DMARCER helps
DMARCER ingests your TLS-RPT reports for you and turns them into something you can act on. Rather than a pile of raw files, you get the failures broken down by type and by sender, so you can see at a glance whether the problem is a certificate, a policy mismatch, or a server that can’t encrypt at all, and exactly which sending source is affected. Paired with hosted MTA-STS, that gives you both halves of the picture: the protection of forced encryption, and the visibility to catch it the moment it slips, while the problem is still small and easy to fix. For a business that’s peace of mind without a specialist; for an MSP it’s early warning across every client’s domain at once.
Related
MTA-STS →
The encryption policy TLS-RPT watches over.
Hosted MTA-STS →
We host the policy and read the reports.
TLS-RPT checker →
Check your record free, in seconds.
See whether your TLS-RPT is in place
Run a free check to see your domain’s posture, then let DMARCER turn your TLS reports into clear, actionable warnings.
Check your domain