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

The 'mode' field determines how a sending mail server should react if it encounters a policy validation failure when attempting to connect to your domain. It dictates whether mail should still be delivered (testing), blocked (enforce), or if MTA-STS should be ignored (none).

Why should I start with 'testing' mode?

Starting with 'testing' mode allows you to monitor and identify any configuration issues or discrepancies with your MTA-STS policy without disrupting legitimate email delivery. It provides crucial feedback through TLS-RPT reports, enabling you to refine your setup before enforcing strict rules.

What happens if I set my MTA-STS policy to 'enforce' and there's a problem?

If your policy is in 'enforce' mode and a problem occurs (e.g., certificate mismatch), sending mail servers will refuse to deliver emails to your domain. This can lead to mail being bounced or delayed, protecting against insecure transmission but potentially causing deliverability issues if not properly tested.

When is it appropriate to use the 'none' mode?

'None' mode is typically used as a temporary measure to quickly disable MTA-STS enforcement, for example, if critical mail flow issues arise that were not caught during testing. It can also be used if you decide to decommission MTA-STS for your domain entirely.

Does the 'version' field influence the 'mode' field?

The 'version' field, such as STSv1 , specifies the protocol version of the MTA-STS policy. While it doesn't directly influence the behavior of the 'mode' field, both are essential components of a valid policy and must be correctly specified for any mode to function as intended. Learn more about the version field .

What is the 'mode' field in an MTA-STS policy? - MTA-STS - Email authentication - Knowledge base

A padlock on an envelope, symbolizing MTA-STS securing email.

The 'mode' field in an MTA-STS policy is a critical component that dictates how receiving mail servers should treat emails from your domain if a TLS (Transport Layer Security) connection cannot be established securely. Essentially, it tells other mail servers how strictly to enforce your security policy. This field is part of the MTA-STS policy file, which is a text file hosted on your web server and discovered via a DNS TXT record.

MTA-STS, or Mail Transfer Agent Strict Transport Security, is an email security standard that ensures email messages are sent over secure, encrypted connections. It helps prevent man-in-the-middle attacks and other forms of eavesdropping during mail transit. The policy file specifies the expected MX records and the cryptographic fingerprints of the valid TLS certificates for those MX hosts. The 'mode' field then defines the action to take when these expectations are not met, providing flexibility during implementation and ongoing enforcement.

Understanding each of the possible values for the 'mode' field is vital for proper deployment and to achieve the desired level of email security for your domain.

Understanding the MTA-STS policy modes

The three MTA-STS policy modes

The MTA-STS specification defines three distinct values for the 'mode' field, each serving a specific purpose in the lifecycle of deploying and maintaining an MTA-STS policy. These modes allow domain owners to gradually introduce and enforce strict TLS requirements without disrupting mail flow.

Mode	Description	Action on policy validation failure
Enforce	Strictly applies the policy. Mail servers must respect the policy.	Mail delivery is blocked to prevent insecure transmission. Reports are sent if TLS-RPT is configured.
Testing	Observes policy violations without blocking email. Useful for initial deployment.	Mail is delivered even if validation fails, but detailed reports are generated (if TLS-RPT is active).
None	Disables MTA-STS for the domain, effectively removing the policy.	No specific action is taken based on MTA-STS policy; mail is delivered as if no policy existed.

The choice of mode directly influences how external mail servers react when attempting to send email to your domain. For instance, in 'enforce' mode, if the sending server cannot establish a secure TLS connection that aligns with your published policy, it will refuse to deliver the email, thus preventing potential eavesdropping or tampering. The RFC 8461 for MTA-STS clearly outlines these behaviors.

The three possible mode values (enforce, testing, none) are integral to how MTA-STS operates. Each plays a role in establishing and maintaining secure email communication.

Using the 'testing' mode

The 'testing' mode is the recommended starting point for any MTA-STS deployment. When your policy is in testing mode, external mail servers will still attempt to validate your MTA-STS policy. However, if a validation failure occurs (e.g., due to an invalid TLS certificate or an MX record mismatch), mail delivery will not be interrupted. Instead, the sending server will deliver the email without TLS encryption or to an unverified server, and critically, it will report the failure if TLS-RPT (TLS Reporting) is also configured.

Example MTA-STS policy in testing modeYAML

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

This passive monitoring phase is invaluable for identifying and resolving any configuration issues with your TLS certificates, MX records, or the MTA-STS policy itself. By observing reports generated during this phase, you can ensure that your setup is correct before moving to a stricter enforcement policy. Without 'testing' mode, deploying MTA-STS could inadvertently lead to legitimate emails being blocked.

Suped can help you with DMARC monitoring and get real-time alerts and actionable AI-powered recommendations to resolve issues. Our unified platform includes MTA-STS reporting, giving you a complete view of your email security. Ensure a smooth transition by carefully monitoring your MTA-STS reports while in 'testing' mode.

Best practice for 'testing' mode

Start with 'testing' mode: Always deploy your MTA-STS policy in 'testing' mode first to gather data and identify potential problems without affecting email delivery.
Configure TLS-RPT: Ensure you have TLS-RPT configured to receive reports on policy validation failures, which are crucial for debugging. This allows you to troubleshoot DMARC reports more effectively.
Monitor reports: Actively review the reports to fix any issues with your infrastructure or policy configuration.

Implementing the 'enforce' mode

Once you are confident that your MTA-STS policy is correctly configured and no issues are reported in 'testing' mode, you can transition to the 'enforce' mode. In enforce mode, external mail servers are instructed to strictly adhere to your policy. If a secure TLS connection cannot be established or if the TLS certificate does not match the expected values (as defined in your policy), the sending mail server must abort mail delivery. This action ensures that your emails are only transmitted securely, protecting them from interception and tampering.

A secure shield with a checkmark, illustrating MTA-STS enforce mode.

The 'enforce' mode is the ultimate goal of MTA-STS implementation, as it provides the strongest protection against downgrade attacks and man-in-the-middle attacks. It signifies that your domain is serious about encrypted email delivery and expects all incoming mail to conform to these security standards. When combined with DMARC monitoring, this creates a robust email security posture.

Before 'enforce' (testing mode)

In 'testing' mode, policy failures result in reports being sent, but email delivery proceeds. This allows for detection of issues without blocking legitimate emails. This is a crucial step before transitioning to a stricter policy.

Risk: Emails may still be sent unencrypted or to unauthorized servers during this phase.
Visibility: Reports provide data on policy non-compliance.

After 'enforce' (strict security)

In 'enforce' mode, policy failures lead to the rejection of email delivery, ensuring that emails are only transmitted securely. This protects your domain from attacks that attempt to downgrade or intercept mail.

Risk: Incorrect configuration could block legitimate emails. Ensure thorough testing beforehand.
Security: Maximum protection against insecure email delivery.

It is important to remember that the max_age field in your MTA-STS policy also plays a role here. It defines how long sending servers should cache your policy. A longer max_age value can reduce DNS lookups but also means that changes to your policy, including mode changes, will take longer to propagate to all sending servers.

The 'none' mode

The 'none' mode essentially disables MTA-STS for your domain. When your policy is set to none mode, sending mail servers will not apply any MTA-STS checks or enforcement when delivering email to your domain. They will treat connections as if no MTA-STS policy exists, reverting to standard SMTP behavior, which may or may not involve opportunistic TLS.

While 'none' mode removes the security benefits of MTA-STS, it has its uses. It can be a necessary step if you need to quickly revert your policy due to unforeseen issues that were not caught during the 'testing' phase, or if you decide to decommission MTA-STS for your domain. It provides a way to gracefully back out of the policy without causing mail flow disruptions.

Example MTA-STS policy in none modeYAML

version: STSv1
mode: none
mx:
  - mail.yourdomain.com
  - *.yourdomain.com
max_age: 86400

It's important to understand that moving to 'none' mode means you are intentionally reducing your email's security posture. It should only be used as a temporary measure or when MTA-STS is no longer required for your domain's email infrastructure. For more details, Microsoft Learn provides guidance on enhancing mail flow with MTA-STS.

Transitioning your MTA-STS policy

The transition from 'testing' to 'enforce' (or 'none') mode is a critical step that requires careful planning and monitoring. The recommended approach is to start with 'testing' mode, gather sufficient data to confirm proper configuration, and only then move to 'enforce'. If issues arise, it may be necessary to revert to 'testing' or even 'none' temporarily to resolve problems before attempting enforcement again.

Continuously monitoring your DMARC and MTA-STS reports is crucial throughout this process. Suped offers a comprehensive platform that not only provides DMARC monitoring but also includes insights into MTA-STS performance. Our AI-powered recommendations help you understand what actions to take to safely transition your policy and strengthen your email security without impacting deliverability.

Remember that consistency across all aspects of your MTA-STS setup, including the MTA-STS policy TXT record and the MX field, is key to successful implementation. Any discrepancies can lead to validation failures, even in 'testing' mode.

Conclusion: securing email delivery

The 'mode' field is a cornerstone of your MTA-STS policy, providing flexibility to deploy and enforce secure email transport according to your domain's readiness and security requirements. By carefully managing this field, starting with 'testing', moving to 'enforce', and only using 'none' when absolutely necessary, you can significantly enhance the security and privacy of your inbound email communications.

Implementing MTA-STS, alongside other email authentication protocols like DMARC, SPF, and DKIM, forms a robust defense against various email-based threats. This layered approach ensures that your domain not only sends authenticated mail but also receives mail securely, protecting both your organization and your recipients.