What does an MTA-STS policy with 'mode: none' mean?

An MTA-STS policy with 'mode: none' indicates that your domain no longer wishes to enforce MTA-STS (Mail Transfer Agent Strict Transport Security). Sending mail servers will treat your domain as if it has no active MTA-STS policy, meaning TLS encryption is no longer mandated by MTA-STS.

When would I use 'none' mode for MTA-STS?

You would typically use 'none' mode to disable an MTA-STS policy, either because you are changing email infrastructure, no longer require MTA-STS for a particular domain, or for troubleshooting purposes. It helps to prevent email delivery issues that might arise from misconfigured 'testing' or 'enforce' policies.

Does 'mode: none' completely disable TLS for my emails?

No, 'mode: none' does not completely disable TLS encryption for your emails. It only disables the *enforcement* of TLS via MTA-STS. Mail servers will still attempt to establish TLS connections based on standard SMTP practices, but without the strict requirements that an MTA-STS 'enforce' policy would impose.

How do I set my MTA-STS policy to 'none' mode?

To set your policy to 'none' mode, you need to update your mta-sts.txt file on your web server to include mode: none . Additionally, you must increment the 'id' tag in the corresponding DNS TXT record for your MTA-STS policy to ensure that external mail servers fetch the updated policy.

Are there any risks associated with using MTA-STS 'none' mode?

The main risk is that by disabling MTA-STS, your domain becomes more vulnerable to downgrade and man-in-the-middle attacks. These attacks could allow adversaries to intercept or alter emails if the connection defaults to an unencrypted or weakly encrypted state. It removes a critical layer of protection for email in transit.

What is the 'none' mode in MTA-STS? - MTA-STS - Email authentication - Knowledge base

Stylized email envelope with a deactivated security padlock, representing MTA-STS 'none' mode

MTA-STS, or Mail Transfer Agent Strict Transport Security, is a crucial security standard designed to protect email communications from various attacks, such as downgrade attacks and man-in-the-middle attacks. It ensures that when one mail server (MTA) sends email to another, the connection is always encrypted using Transport Layer Security (TLS). This prevents attackers from forcing a connection down to an unencrypted state, thereby safeguarding sensitive information during transit. For a more comprehensive understanding of its underlying mechanisms, you can refer to the official RFC 8461 specification.

An MTA-STS policy is published as a text file on a web server and referenced by a DNS TXT record. This policy defines how a sending mail server should treat inbound mail for the domain, specifically regarding TLS encryption. A key part of this policy is the 'mode' field, which dictates the operational state of MTA-STS. There are three possible values for this field: testing, enforce, and none.

While enforce mode provides the highest level of security and testing mode allows for observation without disruption, the 'none' mode serves a distinct and important purpose. It is essentially the off switch for MTA-STS, indicating that a domain no longer wishes to participate in or enforce this security mechanism. Understanding the nuances of each mode is critical for proper email security configuration.

The role of MTA-STS in email security

MTA-STS is a vital component of modern email security, designed to protect the integrity and confidentiality of emails during server-to-server transmission. It works by allowing a domain owner to declare that their mail servers expect secure TLS connections for all incoming mail. This declaration helps prevent passive eavesdropping and active tampering during mail delivery, ensuring that emails are sent over encrypted channels.

The core of MTA-STS relies on a policy file, typically named mta-sts.txt, which is hosted on a well-known HTTPS endpoint. This file contains rules that receiving MTAs (mail servers sending email to your domain) will consult to determine how to establish a secure connection. The most critical rule within this policy is the 'mode' field, which dictates the enforcement level.

The three modes (none, testing, enforce) offer different levels of security and operational impact. Choosing the correct mode is essential for managing your email infrastructure effectively. While testing mode allows for monitoring to ensure compatibility without blocking emails, and enforce mode rigorously applies TLS requirements, 'none' mode serves as a mechanism to opt out or temporarily disable MTA-STS protection.

Mode	Description	Impact on email delivery
None	Treats the domain as if it has no active MTA-STS policy. Removes TLS enforcement.	Email is delivered, but TLS enforcement via MTA-STS is suspended.
Testing	Monitors potential policy violations without rejecting mail. Generates reports.	Email is delivered regardless of TLS failures, but incidents are reported.
Enforce	Requires strict TLS connections for all mail. Rejects non-compliant connections.	Email is delivered only if TLS requirements are met. Otherwise, it is rejected.

Demystifying the 'none' mode

When an MTA-STS policy is set to mode: none, it signals to sending mail servers that the domain no longer expects or requires MTA-STS protection. In essence, it tells them to treat the domain as if it never had an MTA-STS policy in place. This can be likened to removing a security directive rather than actively enforcing one.

The operational impact of 'none' mode is that sending MTAs will discontinue validating TLS encryption against the domain's MTA-STS policy. This means that while TLS encryption might still occur based on standard SMTP negotiations, the mandatory security assurances provided by MTA-STS are no longer in effect. For more specific details on how major providers like Google handle this, their support documentation clarifies that a 'none' policy is used to turn off MTA-STS.

Stylized hand flipping an MTA-STS switch to the 'OFF' position, illustrating 'none' mode activation.

Implementing 'none' mode involves updating your mta-sts.txt policy file and ensuring its corresponding DNS TXT record's 'id' tag is incremented. This change propagates through DNS caches, informing external mail servers that your domain's MTA-STS policy has been deactivated. It's a critical step in managing the lifecycle of your email security protocols.

Example MTA-STS policy file with 'mode: none'yaml

version: STSv1
mode: none
mx: example.com
max_age: 86400

When to use and transition from 'none'

The primary use case for MTA-STS 'none' mode is to gracefully disable or remove an active MTA-STS policy for your domain. This might be necessary if you are decommissioning a mail server, changing email service providers, or if your domain no longer requires the stringent TLS enforcement that MTA-STS provides. It ensures that mail flow isn't interrupted while you transition your email infrastructure or security posture.

Before: Active MTA-STS Policy

Mail servers mandate TLS encryption for inbound emails.
Protects against downgrade and man-in-the-middle attacks.
Requires a correctly configured DNS TXT record and policy file.

After: MTA-STS 'none' Mode

TLS encryption is no longer enforced by MTA-STS.
Email is delivered without MTA-STS specific security checks.
Useful for disabling or troubleshooting MTA-STS policies.

Furthermore, 'none' mode can be a crucial tool for troubleshooting. If an MTA-STS policy in enforce mode is misconfigured, it could lead to legitimate emails being rejected or delayed. Temporarily switching to 'none' mode allows you to quickly restore normal mail flow while you identify and correct the underlying configuration issues without email loss.

Best practices for using 'none' mode

Update the policy file: Ensure your mta-sts.txt file clearly specifies mode: none.
Increment the ID: Always increment the 'id' tag in your MTA-STS DNS TXT record when making changes to your policy, including setting it to 'none'.
Monitor DNS propagation: Allow sufficient time for DNS changes to propagate across the internet before expecting the 'none' mode to take full effect.

Ensuring secure email delivery

While MTA-STS 'none' mode offers flexibility for disabling or troubleshooting your policy, it's crucial to remember that it effectively removes a layer of email security. Email authentication protocols like DMARC, SPF, and DKIM remain vital for protecting your domain from spoofing and ensuring deliverability. Properly managing these records, including your MTA-STS policy, is an ongoing process that requires continuous monitoring and occasional adjustments.

To maintain optimal email security and deliverability, leveraging a comprehensive DMARC monitoring solution is highly recommended. Suped offers a robust platform that goes beyond simple reporting, providing AI-powered recommendations to help you fix issues and strengthen your policy. With real-time alerts, a unified platform for DMARC, SPF, and DKIM, and features like SPF flattening, Suped makes DMARC accessible to everyone, from SMBs to large enterprises, as well as MSPs, ensuring your emails reach their intended inboxes securely.