What is the 'mode' field in an MTA-STS policy?

When you're setting up Mail Transfer Agent Strict Transport Security (MTA-STS), you're taking a significant step to secure your domain's email. MTA-STS is a protocol that helps prevent man-in-the-middle attacks where an attacker could intercept and read or modify emails sent to your domain. It works by telling sending mail servers that they must use an encrypted TLS connection. The core of this system is the MTA-STS policy file, a simple text file you host on a specific subdomain. This policy contains a few key directives, and one of the most important is the mode field. This field dictates the behavior of the policy and determines how strictly it's applied.

The mode field tells sending email servers how to react if they encounter a problem while validating your MTA-STS policy, such as an expired certificate or a mismatch in the mail server name. Getting this setting right is crucial for a smooth and secure rollout.

Suped DMARC monitor

Free forever, no credit card required

Get started for free

Trusted by teams securing millions of inboxes

Your MTA-STS policy can be set to one of three distinct modes. Each serves a different purpose, allowing you to gradually implement and enforce your security policy without disrupting your email flow. The UK government's own documentation on email security standards confirms these are enforce, testing, or none.

Mailmodo says:

Visit website

Mode: This field indicates how the policy should be applied. There are three possible modes: None: The policy is published but not enforced.

Let's break down what each mode does:

• enforce: This is the most secure and the ultimate goal of implementing MTA-STS. In enforce mode, if a sending server cannot establish a secure TLS connection with one of your authorized mail servers, it will not deliver the email. It effectively creates a hard fail, preventing email from being sent over an insecure channel. This mode provides the strongest protection against downgrade attacks.
• testing: This mode is for observation and diagnostics. As Sendmarc explains, a policy in testing mode allows emails to be delivered even if TLS validation fails. However, it instructs sending servers to send TLS-RPT (TLS Reporting) reports detailing any connection issues. This allows you to monitor for potential problems with your configuration before switching to enforce. The IETF, the body that defines these standards, originally referred to this as "report" mode in early drafts.
• none: This mode effectively disables MTA-STS. When the policy mode is none, sending servers will fetch the policy but will not perform any validation or enforcement. It's as if no policy exists. This mode is useful for safely disabling MTA-STS without having to remove the DNS records, which could otherwise cause issues if policies are cached by sending servers.

The recommended approach for rolling out MTA-STS is to do it gradually. You should always start with mode: testing. This gives you the ability to receive and analyze TLS-RPT reports to ensure your mail servers are correctly configured and that all legitimate sending servers can connect securely. You can identify issues with your TLS certificates or MX records without risking the loss of legitimate email.

Sendmarc says:

Visit website

Testing mode: When MTA-STS is in testing mode, it validates connections but doesn't enforce strict TLS requirements. Emails can still be delivered even if the...

Once you have monitored the reports for a sufficient period (typically a few weeks) and are confident that there are no configuration issues, you can then switch the policy to mode: enforce. This final step activates the full protection of MTA-STS, ensuring your organization's email traffic is secure from opportunistic attackers.

In short, the mode field is a powerful switch that controls your MTA-STS policy. Using it correctly, starting with testing and moving to enforce, is the key to a successful and disruption-free implementation.