Introduction
MTA-STS and TLS-RPT (SMTP TLS Reporting) are companion standards. MTA-STS is the policy — "use TLS or don't send" — and TLS-RPT is the feedback channel that tells you when senders couldn't comply. Both are needed for an operational TLS-enforcement posture.
This article covers what each does, how they interact, and why deploying one without the other is half-finished.
Why this topic matters
A common pattern: teams publish MTA-STS, set mode to enforce, and then have no visibility into what's failing. Mail starts to drop and they don't know why. TLS-RPT is what makes the policy operable.
What MTA-STS does
MTA-STS publishes a policy file at HTTPS declaring TLS requirements for inbound mail to your domain. Sending mail servers fetch the policy and enforce TLS on connection.
Modes:
none— declared but not enforced.testing— enforce but report failures rather than block.enforce— block messages that can't establish TLS.
The policy lives at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, with a DNS record at _mta-sts.yourdomain.com pointing to it.
What TLS-RPT does
TLS-RPT (SMTP TLS Reporting, RFC 8460) provides a feedback channel. When a sender encounters a TLS issue with your domain (cert mismatch, downgrade attempt, MTA-STS policy fetch failure), they send you a JSON report describing what went wrong.
The TLS-RPT record:
“text v=TLSRPTv1; rua=mailto:[email protected] “
The rua= destination receives daily aggregate JSON reports of TLS failures.
How they interact
The complete loop:
- You publish MTA-STS — enforce TLS.
- A sender encounters a TLS issue when delivering mail to you.
- MTA-STS in enforce mode causes them to fail the delivery.
- TLS-RPT directs them to send you a report of the failure.
- You read the report, diagnose the issue, fix it.
Without TLS-RPT, the failure happens silently from your perspective. Without MTA-STS, there's no enforcement to fail in the first place.
Step-by-step approach to deploying both
- Publish TLS-RPT first. It's read-only feedback; safe to deploy without risk.
- Publish MTA-STS in testing mode. Failures reported, not blocked.
- Watch TLS-RPT reports for a week. Address any failures.
- Move MTA-STS to enforce. Now real enforcement.
- Continue monitoring for the long tail.
Best practices
- Always deploy together. Policy without reporting is opaque.
- Use a DMARC platform that handles both. Same JSON parsing infrastructure.
- Set retention on TLS-RPT mailbox. Reports accumulate.
- Verify cert validity on MX hosts. Most enforcement failures trace to cert issues.
- Document the policy. Mode changes should be tracked.
Recommended next step
If you have either deployed, check whether you have the other. Most environments have one — either MTA-STS without reporting, or TLS-RPT without policy. Either is half-finished.
FAQ
Can I have MTA-STS without TLS-RPT?
Technically yes, but you lose visibility into failures. Strongly recommend both.
Can I have TLS-RPT without MTA-STS?
Yes, but it only reports failures of other TLS mechanisms (like DANE). Without MTA-STS, you have less to report.
How often do TLS-RPT reports arrive?
Daily, similar to DMARC aggregate reports.
What format are TLS-RPT reports?
JSON, gzipped, delivered by email or HTTPS POST. More compact than DMARC's XML.
Do both work without DMARC?
Yes — they're independent of DMARC. But the modern email security stack pairs them with DMARC for full coverage.
Final thoughts
MTA-STS and TLS-RPT are a pair, not a choice. The policy needs the reporting; the reporting needs the policy. Deploy both together and the transport-security posture is complete and observable.
The work is small. The visibility gain is real.