Mail Transfer Agent Strict Transport Security (MTA-STS) is a security standard designed to protect email in transit. It ensures that when email is sent between servers, the connection is always encrypted using TLS (Transport Layer Security). This prevents man-in-the-middle attacks where an attacker could intercept, read, or modify your emails.
At the heart of an MTA-STS implementation is a policy file. This simple text file, hosted on a web server, tells sending mail servers how to handle emails for your domain. A critical part of this policy is the mode directive, which can be set to one of three values: enforce, testing, or none. While enforce is the ultimate goal for security, the none mode plays a very specific and important role.
What is MTA-STS 'none' mode?
The none mode in an MTA-STS policy is essentially an 'off' switch. When a sending mail server retrieves your MTA-STS policy and sees mode: none, it is instructed to behave as if your domain has no MTA-STS policy at all. Any previously cached policies for your domain are disregarded, and no TLS encryption is enforced by MTA-STS for email delivery.
It's a way to explicitly signal the removal of an active policy. Instead of simply deleting your MTA-STS DNS records and policy file, which could leave sending servers using an old, cached enforce policy, setting the mode to none provides a clear directive to stop enforcing the policy.
When should you use 'none' mode?
The none mode is not for initial setup or normal operation, but it is crucial in specific administrative scenarios:
- Decommissioning MTA-STS. If you decide to no longer use MTA-STS, you can't just delete the records. You must first update your policy file to mode: none and leave it in place. This ensures all sending servers that have your old policy cached will receive the new 'off' signal. As noted in a mailcow community discussion, there's a recommendation to set the mode to 'none' for about two weeks before removing the records to allow caches to expire.
- Migrating email providers. When switching to a new mail service that may have different MX records or TLS certificate names, your old MTA-STS enforce policy would cause delivery failures. Switching to none mode beforehand prevents this disruption during the transition.
- Troubleshooting delivery issues. If you suspect an MTA-STS misconfiguration is causing legitimate emails to be rejected, you can temporarily switch the mode to none to disable enforcement while you diagnose the problem.
How is 'none' different from 'testing'?
It's easy to confuse the none and testing modes. They both allow emails to be delivered even if TLS requirements aren't met, but they serve different purposes.
- testing: This mode is for implementation and monitoring. Sending servers will check your policy and report any validation failures (via TLS-RPT), but they will still deliver the email. It allows you to gather data and ensure your configuration is correct before moving to full enforcement.
- none: This mode effectively tells sending servers to ignore MTA-STS entirely for the domain. It does not generate reports and is meant for disabling the policy. As Jaap Wesselius explains, "Sending MTAs should treat the Policy Domain as though it does not have any active policy."
In short, use testing when you want to turn MTA-STS on, and use none when you want to turn it off.
