MTA-STS policy is still in testing mode
Updated
What this check looks for
Your policy is published but asks senders only to report problems, not to act on them. Mail can still be delivered unencrypted.
Why it matters
Testing mode is the right place to start and the wrong place to stay. Until it is set to enforce, the policy provides reporting but no protection.
When the check passes, your report says: “The MTA-STS policy is enforcing, not merely reporting”.
What it costs your score
When this check fails it removes 4 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.
It shares the email-transport.mta-sts family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.
- Severity
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 4 points
- Family cap
- email-transport.mta-sts · 25
- Category
- Email transport
- Module
- Email mta sts
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Move the policy to mode: enforce once TLS-RPT reports are clean.
In testing mode a downgrade attack still succeeds; it is merely reported.
Publish a TLS-RPT record at
_smtp._tls.‹domain›if there is none, so the failures reach you.Check TLS-RPT reports for two to four weeks and confirm no legitimate sender is failing.
Confirm the
mx:list still matches your live MX hosts, and that each presents a valid certificate for its own name.Change
mode: testingtomode: enforceand update the policyidin the DNS record — senders fetch the policy again only when the id changes.
How to confirm it worked
curl -s https://mta-sts.‹domain›/.well-known/mta-sts.txt — expect mode: enforce
dig +short TXT _mta-sts.‹domain› — expect the new id
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
The policy at https://mta-sts.‹domain›/.well-known/mta-sts.txt sets mode: testing. Per RFC 8461 §5, a sender in testing mode reports failures through TLS-RPT but still delivers the message, including over an unauthenticated connection.
Testing is the intended first step. A sender that implements MTA-STS fetches your policy and tries to deliver only to the MX hosts it lists, over TLS, to a server whose certificate is valid for that host name. Because the mode is testing, it delivers anyway when that fails, and sends a TLS-RPT report about the failure if the domain publishes a reporting record. That is a rehearsal: you learn which of your mail servers would have turned senders away, without losing a message.
What it does not give you is protection. An attacker between a sending server and yours can strip the STARTTLS offer or present a certificate of their own, and the message is still delivered to them.
Move to enforce once the reports have been clean for a few weeks and three things hold: every MX host name matches an mx: line in the policy, each of those hosts presents a certificate that is valid, unexpired and issued for its own name, and the policy file is served reliably over HTTPS. Under enforce a sender that cannot meet those conditions holds the message and retries instead of delivering it unprotected, so a mistake shows up as delayed or bounced mail — which is why the reports come first.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.