Introduction
TLS-RPT (SMTP TLS Reporting, RFC 8460) is the visibility companion to MTA-STS. It tells you when senders couldn't establish TLS to your domain — cert mismatches, downgrade attempts, MTA-STS policy fetch failures. Without TLS-RPT, MTA-STS enforcement is a black box; with it, you have a daily feedback channel.
Why this topic matters
Deploying MTA-STS in enforce mode without TLS-RPT means failures happen silently from your side. Mail drops, senders bounce, and you don't know until someone reports it. TLS-RPT closes that loop.
How TLS-RPT works
You publish a TXT record at _smtp._tls.yourdomain.com:
“text v=TLSRPTv1; rua=mailto:[email protected] “
When a sender encounters a TLS issue with your domain, they generate a JSON report and send it to the rua= address. Reports are usually daily aggregates, gzipped.
What's in a TLS-RPT report
A typical report:
“json { "organization-name": "Google Inc.", "date-range": { "start-datetime": "2026-06-01T00:00:00Z", "end-datetime": "2026-06-02T00:00:00Z" }, "contact-info": "[email protected]", "report-id": "...", "policies": [ { "policy": { "policy-type": "sts", "policy-string": ["version: STSv1", "mode: enforce", ...], "policy-domain": "yourdomain.com" }, "summary": { "total-successful-session-count": 12482, "total-failure-session-count": 7 }, "failure-details": [ { "result-type": "certificate-not-trusted", "sending-mta-ip": "203.0.113.45", "failed-session-count": 5 } ] } ] } “
The structure tells you which sender, what failed, and how often.
Failure types you'll see
certificate-not-trusted— sender saw an invalid cert.starttls-not-supported— sender's TLS-required policy hit your server not supporting STARTTLS.validation-failure— generic TLS handshake failure.sts-policy-fetch-error— sender couldn't retrieve your MTA-STS policy.sts-policy-invalid— policy was malformed or unparseable.
Each maps to a specific configuration issue.
Step-by-step approach to using TLS-RPT
- Publish the record with a destination mailbox.
- Set up automated parsing. Raw JSON is fine for a few reports, painful at scale.
- Read the first weeks of reports. Build the baseline.
- Address failures. Cert issues, MX config drift, MTA-STS policy errors.
- Monitor weekly. New failures often indicate sender-side changes.
Best practices
- Pair with MTA-STS always. Otherwise the reporting target is unclear.
- Route to a dedicated mailbox. Reports can be voluminous.
- Use a DMARC platform that parses TLS-RPT. Most modern platforms include it.
- Watch for trends, not individual reports. A single failure may be transient; a pattern is a configuration issue.
- Document failure resolutions. Build institutional knowledge of common causes.
Recommended next step
If you have MTA-STS but no TLS-RPT, publish the TLS-RPT record this week. It's read-only — zero risk — and immediate visibility gain.
FAQ
Do all senders that hit failures send reports?
Major providers (Google, Microsoft) do reliably. Smaller senders may not. Most reports come from the large providers.
Can TLS-RPT replace MTA-STS?
No — it's reporting only. MTA-STS provides the enforcement; TLS-RPT provides the visibility.
What's the difference from DMARC aggregate reports?
DMARC reports cover authentication failures. TLS-RPT covers transport TLS failures. Different layers.
How big are TLS-RPT reports?
Usually small — a few KB per sender per day. Smaller than DMARC reports.
Should I keep historical TLS-RPT reports?
30-90 days is typical retention. Long enough to spot patterns, short enough to manage storage.
Final thoughts
TLS-RPT is the feedback channel that makes MTA-STS operational. The two together give you both the enforcement and the visibility needed for transport security.
Deployment is small, visibility gain is real, and the steady-state monitoring fits inside the same DMARC platform you're already running.