MTA-STS and TLS-RPT: A Practical Setup and Troubleshooting Guide
Understand MTA-STS policies and TLS reporting, check the required records and plan a careful rollout before enforcing transport security.
MTA-STS and TLS-RPT address a different question from SPF, DKIM and DMARC: how mail travels to your domain. Before adding records, decide who will maintain the policy, who will receive reports and how you will investigate failures.
What each part does
MTA-STS lets a receiving domain publish a policy for supporting senders to require TLS and validate the destination mail server. Its DNS discovery record points senders toward an HTTPS policy.
TLS-RPT publishes a destination for aggregate transport-security reports. It provides visibility; it does not enforce encryption. Participating senders can report successes and failures, so an empty inbox is not proof that delivery is healthy.
Start by checking your MX records, then inspect MTA-STS and TLS-RPT separately.
The records and policy file
For an example domain, MTA-STS discovery uses a TXT record at:
_mta-sts.example.com
An illustrative value is:
v=STSv1; id=2026101701
The policy is served at:
https://mta-sts.example.com/.well-known/mta-sts.txt
A testing policy might contain:
version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400
Replace the MX hostname with your real receiving infrastructure. This is an example, not a ready-to-paste policy for every domain. Update the DNS policy identifier when changing the policy so senders can detect an update.
TLS-RPT uses a separate TXT record at _smtp._tls.example.com:
v=TLSRPTv1; rua=mailto:tls-reports@example.com
Use a monitored destination capable of handling report attachments. Publishing a report address does not create that mailbox.
A practical rollout checklist
- Inventory receiving hosts. Compare your current MX results with your mail provider's configuration, including backup hosts.
- Assign ownership. Record who manages DNS, the HTTPS policy endpoint, certificates and report processing.
- Publish and inspect. Check both the discovery record and the fetched policy. A DNS record alone is insufficient.
- Start with testing. Review report data and investigate mismatches before considering enforcement.
- Plan mail migrations. Include policy updates in the same change plan as MX or provider changes.
- Keep monitoring. Recheck after certificate renewals, hosting changes and mail routing changes.
Keep a change log with the previous policy, the new policy, the operator and the date. That makes a delivery incident easier to trace.
Testing versus enforce
In testing mode, policy failures can be reported without requiring the sender to block delivery because of that policy. In enforce mode, supporting senders must not deliver through a connection that fails the applicable policy checks; mail can be deferred.
A cached policy can remain relevant until it expires. Do not assume that removing the discovery record immediately reverses an enforcement rollout. Make your rollback plan before switching modes.
Investigate failures in the right order
| Observation | First investigation |
|---|---|
| Discovery record is present but policy retrieval fails | HTTPS hostname, certificate and exact file path |
| Policy names a host you no longer use | Mail migration records and current MX configuration |
| TLS reports show certificate failures | Certificate validity and the receiving host involved |
| No reports arrive | Reporting address, ingestion pipeline and participating senders |
| A checker cannot complete its request | Distinguish a tool or network error from a confirmed policy defect |
Save the exact finding and timestamp before editing anything. Change one relevant setting at a time, then repeat the checks.
Frequently asked questions
Does this replace SPF, DKIM or DMARC?
No. Keep your authentication checks separate. MTA-STS and TLS-RPT concern SMTP transport security, while authentication addresses other aspects of the message and its sender.
Does a valid policy prove every delivery is encrypted?
No. Configuration checks show what is published at the time of the lookup. Sender support and actual delivery behavior still matter.
Should I enable enforce immediately?
First confirm the receiving infrastructure and policy work together. Use testing, review evidence and arrange monitoring before enforcement.
Will this improve my inbox placement?
Do not use inbox placement as the success criterion for this rollout. Track policy correctness, transport failures and delivery incidents instead.
Next checks
Use the MTA-STS Checker, TLS-RPT Record Checker and MX Record Checker together. Record their findings alongside your provider's settings and report data.