MTA-STS vs TLS-RPT: What’s the Difference?

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:

1. You publish MTA-STS: enforce TLS.
2. A sender encounters a TLS issue when delivering mail to you.
3. MTA-STS in enforce mode causes them to fail the delivery.
4. TLS-RPT directs them to send you a report of the failure.
5. 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

1. Publish TLS-RPT first. It's read-only feedback; safe to deploy without risk.
2. Publish MTA-STS in testing mode. Failures reported, not blocked.
3. Watch TLS-RPT reports for a week. Address any failures.
4. Move MTA-STS to enforce. Now real enforcement.
5. 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.