MTA-STS Testing Mode vs Enforce: When to Switch

Testing vs Enforce: The Key Difference

Your MTA-STS policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt declares a mode:

Testing mode:

version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 86400

Enforce mode:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 604800

In testing, senders log failures but deliver anyway. In enforce, senders drop the message if TLS fails. That's a critical difference for legitimate email delivery.

The Safe Path to Enforce

Step 1: Deploy in Testing Mode

Publish your MTA-STS DNS record and policy file with mode: testing. Set up TLS-RPT to receive reports about connection failures.

Step 2: Monitor TLS-RPT Reports (2-4 Weeks)

TLS-RPT reports show you:

• Which senders attempted connections
• Whether TLS succeeded or failed
• The failure reason (certificate mismatch, expired cert, etc.)

Look for failures from legitimate senders. Common causes:

• Your MX certificate expired or doesn't match the hostname
• A sending server doesn't support TLS at all (rare in 2026, but exists)
• Intermediate certificate chain issues

Step 3: Fix Issues

Before switching to enforce, resolve every legitimate failure:

• Ensure your MX server certificates are valid and match the hostnames listed in your policy
• Verify certificate chain is complete
• Confirm all MX hosts listed in the policy actually accept TLS connections

Step 4: Switch to Enforce

Update your policy file to mode: enforce and increase max_age to a longer value (604800 = 1 week is common). Update the id= in your DNS TXT record to trigger senders to re-fetch the policy.

Practitioner note: Unlike DMARC where p=reject can block important outbound email, MTA-STS enforce mostly affects inbound email from poorly configured senders. In practice, nearly every legitimate mail server supports TLS in 2026. The risk is lower than most people expect.

When Not to Enforce

Stay in testing if:

• You receive email from legacy systems or government servers with known TLS issues
• Your MX certificates rotate frequently and you're not confident in automation
• You have multiple MX hosts and can't verify TLS on all of them

Practitioner note: I've yet to see a properly configured domain lose legitimate email from switching MTA-STS to enforce. The servers that fail TLS in 2026 are almost exclusively spam sources. But monitoring first is still the right call.

max_age Considerations

In testing, keep max_age short (86400 = 1 day) so senders re-check your policy frequently. In enforce, increase to 604800 (1 week) or longer. A longer max_age provides stronger security because attackers have a shorter window to exploit policy expiry.

If you want MTA-STS deployed correctly alongside your DMARC and SPF setup, schedule a consultation.

Sources

• RFC 8461: SMTP MTA Strict Transport Security
• RFC 8460: SMTP TLS Reporting
• Google Workspace Admin Help: MTA-STS and TLS Reporting

---

v1.0 · April 2026