Rolling Out MTA-STS Safely: From Testing to Enforce Without Mail Loss

MTA-STS is quick to enable: a DNS record, a policy file over HTTPS, done. The tricky part is the last step, the switch from testing to enforce. That single switch decides whether enforced transport encryption becomes reliable protection or a source of silent delivery failures. Anyone who turns it on too early risks legitimate emails from partners with small TLS weaknesses suddenly being rejected.

This guide does not cover the basics, you will find those in What Is MTA-STS. It covers the process and the risk management: how to move in phases from none through testing to enforce, which criteria justify the switch, what role max_age plays and how a rollback succeeds without mail loss.

Why switching to enforce is the critical moment

TL;DR: Roll MTA-STS out in phases: none, then testing, then enforce. In testing mode you collect reports through TLS-RPT and watch the failure rate without endangering mail flow. You move to enforce only once the reports are stable over several days and no unexplained failure remains. Keep max_age short during the rollout so a rollback takes effect quickly, and raise it only in stable operation.

In enforce mode a sending server aborts delivery when the TLS connection to your mail server does not match the policy. That is exactly the desired behaviour against downgrade attacks. But it also hits every legitimate sender whose connection fails on a real detail: an expired certificate on your side, a mail server missing from the policy, or a hostname that does not match the certificate.

The point is that enforce forgives no configuration errors. A problem that only shows up as a line in a report during testing becomes an undelivered email under enforce. The switch is therefore not a question of courage but a question of solid data.

The phased rollout: none, testing, enforce

MTA-STS defines three operating modes that together form a low-risk adoption path. You run through them in sequence, not in parallel.

In preparation you make sure the policy file mta-sts.txt names all receiving mail servers of your domain correctly and that their certificates are valid. Only then do you publish the policy in testing mode. This step is deliberately harmless: even if your mail server list were faulty, not a single email would be rejected in testing mode.

Testing mode: collecting and reading reports

The testing mode is not a waiting room but an active measurement phase. For it to work, TLS-RPT is mandatory. Through an additional DNS record you request daily reports in which receiving and sending platforms report how many connections were encrypted successfully and why failed attempts failed.

Per reporting organisation, a TLS-RPT report provides, among other things:

• the number of successful TLS connections to your mail servers,
• the number of failed connections,
• a failure type, for example certificate-expired, certificate-host-mismatch or validation-failure,
• the affected destination hostname.

The important thing is to read these reports actively, not just archive them. Every reported failure is a free early warning in testing mode: under enforce, an email would have been stuck at that point. If reports of type certificate-host-mismatch accumulate, a hostname is probably missing from your policy or a mail server is presenting a certificate with an unexpected name.

Keep a particular eye on the failure rate relative to total volume. A handful of failures from a single misconfigured counterpart is different from a consistently high failure rate across many senders. The latter almost always points to a problem on your own side and must be fixed before the switch.

Concrete criteria for switching to enforce

Instead of switching on a hunch, work through a short checklist. Only when every point is met is enforce justifiable:

1. Stable reports over several days. The TLS-RPT reports show a constant picture over a connected period, for example several days to weeks, with no new unexplained failures.
2. Failure rate near zero. The remaining failures are statistically negligible and individually traceable.
3. No unexplained failures. Every remaining failure is explained and either fixed or clearly attributable to the counterpart, not to your own configuration.
4. Complete mail server list. All of your own receiving mail servers are listed in the policy, including backup MX and any gateway hosts.
5. Valid, matching certificates. Every listed mail server presents a valid certificate whose name matches the expected identity and whose expiry is not imminent.

The most common mistake here is too short an observation phase. Some business partners write to you only every few weeks. If those senders do not appear in the reports yet, you lack the data for exactly those connections. So let testing run long enough that several complete reporting cycles are available.

max_age and caching: short in the rollout, long in operation

The max_age parameter in the policy file sets how long a sending server may cache your policy, given in seconds. This value has a direct consequence for your risk management, because it determines how quickly changes take effect.

The trade-off is clear: a long max_age increases security, because an attacker cannot simply replace a cached policy with a manipulated one. But that same toughness becomes a problem when you have to backtrack yourself. If sending servers have loaded enforce with a long max_age, they hold on to it until the value expires, even if you changed your policy long ago.

The consequence for the procedure: keep max_age deliberately short during the rollout and the first days under enforce. Raise it only once enforce has run without incident for a longer period. That way you stay able to act throughout the risky phase.

How to roll back safely

If unexpected delivery problems appear after switching to enforce, an orderly rollback is more important than root-cause analysis in live operation. Proceed in this order:

1. Reset the mode. In the file mta-sts.txt, change the mode from enforce to testing. Violations are then only reported again instead of aborting delivery.
2. Increment the version identifier. Update the version identifier in the DNS TXT record at _mta-sts. Only then do sending servers recognise that the policy has changed and load the new version.
3. Wait out the caching. Servers that still cache the enforce policy keep it until max_age expires. A short max_age shortens this window to hours.
4. Stop completely if needed. If MTA-STS should pause entirely, set the mode to none. This withdraws enforcement in a controlled way instead of deleting the DNS record outright.

This procedure underlines once more why a short max_age during adoption is not a detail but your most important emergency brake. Preparing here turns a potential mail outage into a short, manageable incident.

Steering the rollout with Conbool MailGuard

The real effort with MTA-STS is not the one-off activation but the ongoing operation of the rollout: serving the policy file over HTTPS permanently, keeping the subdomain certificate valid, consolidating the TLS-RPT reports of many senders and deriving a solid statement about the failure rate. This is exactly where Conbool MailGuard comes in.

MailGuard provides the policy and subdomain, keeps the certificate valid automatically and guides the transition from testing to enforce. The incoming TLS reports are consolidated in one place, so you do not have to read the failure rate out of raw report files but see directly whether the switch-over criteria are met. You can check the current state of your domain in advance with the free transport security check, and details of the managed solution are on the MTA-STS page.

Frequently asked questions

How long should I keep MTA-STS in testing mode?

The standard sets no fixed deadline. A workable rule of thumb is at least two to four weeks, so several complete TLS-RPT reporting cycles are available and partners who communicate rarely are also captured. What matters is not the raw duration but that the reports are stable over several days and no unexplained failures remain.

How do I know it is safe to switch to enforce?

The switch is safe when the TLS-RPT reports stay stable over several days, the failure rate is near zero and every remaining failure is explained and fixed. In addition, all of your own receiving mail servers should be listed correctly in the policy and present valid certificates that match the expected identity. If violations remain unexplained in testing mode, enforce is still premature.

What role does max_age play in the rollout?

max_age sets how long a sending server caches your policy. During the rollout a short value makes sense, for example a few hours to a day, because corrections and a possible rollback then take effect quickly. In stable production you choose a longer value, often several weeks, because it increases robustness against manipulation. A long max_age does slow down a later rollback, so it should only be raised after enforce runs cleanly.

How do I roll back enforce if something breaks?

In the policy file mta-sts.txt, set the mode back from enforce to testing and update the version identifier in the DNS TXT record so sending servers recognise the changed policy. Sending servers that still hold the old policy keep enforce until max_age expires, which is exactly why you keep max_age short during the rollout. A full stop is achieved through the mode none.

How is reading the reports different from just enabling MTA-STS?

Enabling the policy only publishes the DNS record and the policy file. Only the ongoing analysis of TLS-RPT reports shows whether enforced encryption works in practice, which partners connect cleanly and where certificate or configuration errors exist. Without this visibility the switch to enforce is a blind flight. Conbool MailGuard therefore consolidates the reports in one place and makes the failure rate visible.

Conclusion

A safe MTA-STS rollout is less a technical task than a procedural one. The modes testing and enforce are the tools, but the risk management lies in between: in the consistent analysis of TLS-RPT reports, in clear switch-over criteria and in a short max_age that always allows you a rollback. Whoever proceeds this way reaches enforced transport encryption without a single lost business message.

The next step is yours: check your domain with the transport security check and see how Conbool MailGuard handles the rollout from testing to enforce.

Further reading:

• What Is MTA-STS? How it works and how to set it up
• Setting up MTA-STS for Microsoft 365
• How to read a TLS-RPT report
• MTA-STS vs DANE: the comparison