Mail Transfer Agent Strict Transport Security (MTA-STS) is a crucial security standard designed to protect email in transit. It ensures that when mail servers communicate, they do so over an encrypted TLS connection, preventing eavesdropping and man-in-the-middle attacks. But for it to work, a specific process must be followed, starting with a DNS record and leading to a policy file hosted on a web server. So, what happens when that process breaks down and the policy file can't be found?
How MTA-STS works
To understand the impact of a missing policy file, we first need to understand how MTA-STS functions. When a sending mail server wants to send an email to a domain using MTA-STS, it performs a few steps:
- DNS check: The sender queries the DNS for a TXT record at _mta-sts.yourdomain.com.
- Policy retrieval: This DNS record indicates that a policy exists and directs the sending server to a specific subdomain, like mta-sts.yourdomain.com. The server then attempts to fetch a text file from a well-known URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.
- Policy caching: If the file is successfully retrieved, the sender caches the policy for a duration specified by the max_age value within the policy itself.
This policy file contains vital instructions, including the expected mail server names (MX records) and the policy mode, which can be enforce, testing, or none. The problem arises when the DNS record exists, but the policy file does not.
The consequences of a missing policy file
If a sending server finds your MTA-STS DNS record but cannot retrieve the policy file from the specified HTTPS URL, you have a configuration error. This is a common issue seen in forums, with users reporting errors like "MTA-STS policy is missing". The exact outcome depends on whether the sending server has a previously cached policy for your domain.
Scenario 1: No cached policy exists
If this is the first time a particular server is trying to send you an email, or if its cache has long expired, it has no prior policy to fall back on. In this case, the MTA-STS check effectively fails open. The sending server will typically revert to the default SMTP behavior, which may mean attempting a TLS connection without validation or, worse, sending the email in plaintext. This completely negates the protection MTA-STS is meant to offer.
Your email communication becomes vulnerable to downgrade attacks, where an active attacker can intercept the connection and strip the encryption.
Scenario 2: A valid policy is cached
This is where the max_age directive in your policy becomes a lifesaver. MTA-STS is designed to be resilient against temporary failures. If a sending server has successfully fetched your policy in the past, it will have it stored in its cache. When it fails to retrieve a new policy, it will continue to use the old, cached version until it expires.
This is a critical feature. It means that a temporary web server outage or a brief DNS issue won't immediately compromise your email security or break your mail flow. The sending server will keep enforcing the last known good policy. However, once the max_age duration is exceeded, you are back in the first scenario, and your mail delivery could be at risk if your policy was set to enforce.
How to detect and fix a missing policy file
A missing MTA-STS policy file is a silent failure that undermines your security posture. The best way to become aware of this and other TLS-related delivery issues is by implementing TLS Reporting (TLS-RPT).
TLS-RPT is a companion standard to MTA-STS. You set it up by adding a separate DNS TXT record that tells sending servers where to send diagnostic reports about email delivery successes and failures. If a sender fails to fetch your MTA-STS policy, it will send you a report detailing the problem. This allows you to proactively identify and fix issues, such as an incorrect URL, an invalid SSL certificate, or the file simply not being present.
Ultimately, having an MTA-STS DNS record without a corresponding, accessible policy file is worse than having no MTA-STS at all. It creates a false sense of security while leaving your email vulnerable. It's essential to ensure your policy file is correctly hosted and accessible over HTTPS, and to use TLS-RPT to monitor for any fetch failures.
What is the file name for an MTA-STS policy?
What port does MTA-STS typically use for policy fetching?
What is the directory path for the MTA-STS policy file?
Does MTA-STS require a dedicated server for its policy file?
What is the sequence of steps for an MTA to retrieve an MTA-STS policy?
What is the format of the MTA-STS policy file?
