Dr.Who
← blog

MTA-STS testing vs enforce: roll out in testing first, then enforce

· mta-sts · tls-rpt · email-security · smtp · deliverability

mta-ststls-rptemail-securitysmtpdeliverability

Start an MTA-STS rollout in testing mode, not enforce. In testing mode a sending server checks your policy and reports any TLS or MX mismatch through TLS-RPT, but it still delivers the message normally. enforce mode is the opposite: a sender that cannot match your policy — wrong MX, expired or untrusted certificate — will refuse to deliver and defer the mail. The safe path (RFC 8461) is testing first, watch reports until they are clean, then promote to enforce.

The three modes

The mode line in your policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt takes one of three values:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800
  • none — you publish a policy but ask senders to take no action. Useful only to wind a policy down before removing it.
  • testing — senders evaluate the policy and, on failure, send you a TLS-RPT aggregate report, but delivery still happens over whatever TLS is available. Failures are visible, not fatal.
  • enforce — senders that cannot establish a connection matching the policy (a listed mx host, valid PKIX certificate, TLS) must not deliver. The message is deferred and eventually bounces if the mismatch persists.

Why enforce-first is dangerous

enforce turns every misconfiguration into deferred or lost mail, and the failures are silent from your side — the sender is the one that refuses. Common ways enforce-first bites:

  • An MX hostname in production is not listed in the policy mx: set, so mail to that route is refused.
  • A certificate on one MX host expired, or its name does not match, so PKIX validation fails for that connection.
  • A secondary or backup MX has weaker TLS than the policy demands.

In testing mode every one of these would have shown up as a failure-details entry in your TLS-RPT reports while mail kept flowing. In enforce mode the same conditions strand legitimate mail.

Recommended rollout

  1. Publish TLS-RPT first so you have somewhere to receive feedback:
_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"
  1. Publish the MTA-STS policy in mode: testing plus its _mta-sts TXT record with a fresh id.
  2. Collect TLS-RPT for at least one or two reporting cycles. Confirm total-failure-session-count is zero and no failure-details reference your MX hosts.
  3. Change the policy file to mode: enforce and bump the id in the _mta-sts TXT record so senders re-fetch — otherwise they keep the cached testing policy.
Verify your policy mode and MX list →

Further reading