MTA-STS in testing mode: move to enforce
What MTA-STS testing and none modes do, how to use TLS-RPT reports to decide when to enforce, and how to change mode without senders missing it.
By the Domain Health Hub team · Updated
- In testing mode senders report problems but still deliver, so there's no protection yet.
- mode: none switches MTA-STS off, and is how a domain withdraws a policy.
- Move to enforce once TLS-RPT reports show no failures for a couple of weeks, and change the id.
What the error means
RFC 8461 defines three modes. enforce tells senders not to deliver unless they can make a verified, encrypted connection to a listed mail server. testing asks them to report failures (through TLS-RPT) but deliver anyway. none means there is no policy, and is the documented way to withdraw one.
Testing is the right place to start, but it gives no protection against downgrade attacks. We flag testing as something to finish, and none as MTA-STS being switched off.
When it's safe to enforce
- A TLS-RPT record is in place and reports are arriving.
- Reports show no failed sessions for a couple of weeks.
- Every MX host is in the policy and has a valid certificate for its name.
How to confirm it
Open the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt (with your domain) and read the mode: line.
How to fix it
Change mode: testing (or none) to mode: enforce in the policy file, then publish a new id in the _mta-sts TXT record. Without the new id, senders keep their cached testing policy until it expires.
v=STSv1; id=20261021T090000
Microsoft 365 and Google Workspace
Both providers' mail servers have valid certificates for their MX host names, so once the mx: lines match your MX records, enforcing is low risk.
Questions
Can enforce mode stop my email?
Only if a sender can't make a valid encrypted connection to a listed mail server: a server missing from the policy, or an expired or wrong certificate on it. TLS-RPT reports in testing mode show those problems before they matter.
Why change the id?
Senders cache the policy for max_age seconds and only fetch it again when the id in the TXT record changes.
Hear about it the day it breaks.
Daily checks on every client domain, alerts when something changes, and a monthly report card your clients will understand.