Configure MTA-STS and TLS-RPT
Publish MTA-STS policy and TLS reporting.
Objective
Secure transport reporting
Deploy MTA-STS and TLS-RPT where appropriate.
Starting state
Inbound MX hosts support STARTTLS; policy and reporting not yet published
Prerequisites
- Control of DNS and HTTPS host for mta-sts policy
- Stable MX hostnames
Estimated time
1–2 hours
Difficulty
intermediate
Required access
- DNS
- ESP or MTA admin
Inputs
- Domain
- MX host list
- TLS-RPT rua address
Step-by-step instructions
- Publish TLS-RPTAdd _smtp._tls TXT so TLS failure reports have a destination. Example: v=TLSRPTv1; rua=mailto:tls-reports@example.com
- Host the MTA-STS policyServe a valid policy file over HTTPS at mta-sts.example.com/.well-known/mta-sts.txt (example hostname).
- Publish the MTA-STS DNS TXTAdd _mta-sts TXT with id= and mode= (start with testing if unsure). Example shape: v=STSv1; id=20260711T120000;
- Validate and consider enforceConfirm policy fetch and reporting, then move mode to enforce when MX/TLS are proven stable. Rollback: set mode=testing or remove _mta-sts until HTTPS/MX are fixed.
Verification
- Policy URL returns 200 with expected policy
- _mta-sts and TLS-RPT TXT resolve
Common mistakes
- Enforcing with mismatched MX hostnames
- Broken HTTPS on the policy host
- Start in testing mode how long?
- Are all MX names covered by the policy?
Rollback / recovery
- Set mode=testing or remove _mta-sts until HTTPS/MX are fixed
Expected outcome
MTA-STS and TLS-RPT are published so inbound TLS policy can be monitored and enforced safely.
When to escalate
- Production mail impacted unexpectedly