MTA-STS, which stands for Mail Transfer Agent Strict Transport Security, is a security standard designed to protect email in transit. Its main job is to ensure that when email is exchanged between mail servers, it happens over a secure, encrypted connection. This helps prevent man-in-the-middle attacks, where an attacker could intercept, read, or alter your emails. As Mailmodo puts it, it's a protocol that ensures emails are sent over an encrypted SMTP connection.
When you implement MTA-STS, you publish a policy that tells other mail servers how to handle emails sent to your domain. This policy has different modes, with the most common ones being enforce, testing, and none. The 'testing' mode is a critical, and often misunderstood, part of this process.
What is MTA-STS 'testing' mode?
The MTA-STS 'testing' mode is essentially a monitoring phase. When you set your policy mode to testing, you're telling other mail servers to check your MTA-STS policy and report on whether they can successfully connect using TLS, but not to actually block emails if they can't. It's like a trial run for your email security policy.
This mode allows you to deploy the policy and gather data without any risk of disrupting your email flow. You get to see how sending servers are interacting with your policy before you commit to enforcing it, which could otherwise lead to lost emails if something is misconfigured.
Why 'testing' mode is a critical first step
Starting with 'testing' mode is the recommended best practice for any MTA-STS deployment. It’s what the official RFC 8461 documentation refers to as a "soft deployment." The primary goal is to identify potential policy failures before they can cause any real damage.
Using 'testing' mode allows you to:
- Identify configuration issues. You might have typos in your policy file or issues with your mail server's TLS certificates. Testing mode helps you catch these early.
- Gather data. When paired with TLS Reporting (TLS-RPT), you receive reports on which connections would have failed if your policy were set to 'enforce'.
- Ensure compatibility. You can verify that important partners and services are able to connect to your mail servers securely according to your policy.
- Prevent mail loss. Most importantly, it prevents a situation where legitimate emails are blocked because of a strict policy that hasn't been properly vetted.
The role of TLS-RPT with 'testing' mode
MTA-STS 'testing' mode is most powerful when used alongside TLS Reporting (TLS-RPT). TLS-RPT is a separate standard that enables sending mail servers to send you reports about TLS connection successes and failures.
When your policy is in 'testing' mode, these reports become your guide. They will detail any policy application failures, such as certificate validation problems or a failure to negotiate a secure connection. These are the exact issues that would cause email delivery to fail under an 'enforce' policy. By analyzing these reports during the testing phase, you can proactively fix any problems with your mail server configuration or work with sending parties to resolve issues on their end.
Transitioning from 'testing' to 'enforce'
The process is straightforward. You begin by publishing your MTA-STS and TLS-RPT records with the policy set to testing. Then, you monitor the TLS-RPT reports for a period of time, typically a few weeks, to gather sufficient data.
Once you are confident that there are no significant, recurring failures in your reports, you can safely transition. This involves updating your MTA-STS policy file, changing the mode from mode: testing to mode: enforce. After updating the policy file, you'll update the policy ID in your _mta-sts DNS record to signal to the world that a new policy is available. At that point, MTA-STS is fully active and protecting your domain's email.
