When setting up MTA-STS (Mail Transfer Agent Strict Transport Security), you're creating a policy to tell other mail servers how they should securely connect to your mail servers. A crucial part of this policy is the mode key. This key defines how strictly sending mail servers should adhere to your security requirements. It's the central switch that controls the enforcement level of your entire MTA-STS setup.
There are three possible values for the mode directive in an MTA-STS policy. Each one represents a different stage of implementation, from monitoring to full enforcement. Understanding these modes is essential for a smooth and successful rollout.
The three MTA-STS modes
The MTA-STS standard specifies three distinct modes that a domain can publish in its policy file. These modes dictate the behavior of sending MTAs when they fail to establish a secure connection according to the policy's rules.
The three possible values for the mode directive are:
- enforce: This is the strictest mode. It tells sending servers to refuse to deliver email if a secure, validated TLS connection cannot be established.
- testing: This mode is for monitoring. It requests that sending servers send reports about any policy failures (via TLS-RPT) but still deliver the email regardless of those failures.
- none: This mode effectively disables the MTA-STS policy, telling sending servers to behave as if no policy were present. It's used to gracefully remove MTA-STS protections.
Mode: enforce
The enforce mode is the ultimate goal of implementing MTA-STS. When your policy is in this mode, you are instructing sending mail servers that they must establish a secure connection according to your rules. This means the connection must use TLS 1.2 or higher, and the certificate presented by your mail server must be valid and match one of the MX hosts listed in your policy.
If any of these conditions are not met, the sending server is required to treat it as a delivery failure and should not send the email. This prevents man-in-the-middle attacks where an attacker might try to downgrade the connection to be unencrypted. Moving to enforce should only be done after a thorough testing period to avoid accidentally blocking legitimate email.
Mode: testing
The testing mode is a crucial intermediate step. It allows you to publish a policy without actually enforcing it. Sending servers will fetch and evaluate your policy as if it were in enforce mode, but they will not block email delivery if the validation fails.
This mode is designed to be used with TLS Reporting (TLS-RPT). While in testing mode, you can collect reports about any connection issues or policy misconfigurations. This allows you to identify and fix problems, such as an incorrect MX record in your policy or a certificate issue, before switching to enforce and risking lost emails.
Mode: none
The none mode is essentially an 'off' switch. When a sending server sees a policy with mode: none, it is instructed to completely ignore the MTA-STS policy for that domain.
This mode is useful if you need to temporarily or permanently disable MTA-STS for your domain. Because policies are cached by sending servers for the duration specified by the max_age value, simply deleting your policy file is not enough. You must first switch the mode to none and wait for the old policies to expire from sender caches before removing the DNS record and policy file. This ensures a clean and graceful removal of your policy.
What is the file name for an MTA-STS policy?
What DNS record type is used for MTA-STS policy discovery?
What is the 'version' field in an MTA-STS policy?
What port does MTA-STS typically use for policy fetching?
What is the 'mode' field in an MTA-STS policy?
What is the 'mx' field in an MTA-STS policy used for?
