What is the directory path for the MTA-STS policy file?
Michael Ko
Co-founder & CEO, Suped
Published 14 Apr 2025
Updated 7 Oct 2025
7 min read
When implementing Mail Transfer Agent Strict Transport Security (MTA-STS) to bolster your email security, understanding where to place the policy file is crucial. This specific location ensures that receiving mail servers can reliably discover and enforce your domain's TLS policy, protecting your outbound emails from eavesdropping and tampering. The standardization of this path is what makes MTA-STS an effective defense against opportunistic TLS downgrade attacks.
The path isn't arbitrary, but rather a carefully chosen, well-known Uniform Resource Identifier (URI) that all compliant MTAs are programmed to check. This design choice prevents attackers from manipulating the discovery process. If the policy file isn't exactly where it's expected, mail servers won't find it, and your domain won't benefit from the enhanced security that MTA-STS provides.
A misconfigured policy file location is a common pitfall that can lead to significant security gaps, leaving your email traffic vulnerable. Properly setting up this path is as important as the content of the policy itself. We'll explore the precise directory, its components, and the underlying reasons behind this specific structure.
The well-known path structure
The exact MTA-STS policy directory path
The MTA-STS policy file must be hosted at a very specific HTTPS URL for email sending servers (Mail Transfer Agents) to discover it correctly. This ensures a consistent and predictable mechanism for policy retrieval across the internet. The exact path is structured to reside within a special directory designed for well-known URI locations.
Specifically, the MTA-STS policy file, which has a specific file name for an MTA-STS policy, should be accessible via HTTPS at the following URL format:
Here's a breakdown of each part of this critical path:
Subdomain: The policy file must be hosted on the mta-sts.your-domain.com subdomain. This is a specific requirement, not an option, and is crucial for proper MTA-STS policy discovery.
Protocol: It must be accessed over HTTPS. This encryption is vital for ensuring the integrity and authenticity of the policy file itself, preventing any tampering during retrieval. MTA-STS explicitly uses HTTPS for policy retrieval.
Well-known directory: The path includes /.well-known/. This is a standardized directory for publishing site-wide metadata, as defined by RFC 8615. It signals to clients that they can find various service-specific files here.
Policy file: The file itself must be named mta-sts.txt. This standardized naming further aids in the reliable discovery of the MTA-STS policy file format.
Adhering to this exact path is non-negotiable for MTA-STS to function correctly and provide the intended security benefits to your email communications.
Hosting and security requirements
Hosting requirements for the policy file
To correctly host your MTA-STS policy file, you'll need a web server (like Apache or Nginx) configured to serve content over HTTPS for the mta-sts.your-domain.com subdomain. This means you'll need to obtain and install a valid TLS certificate for this subdomain, ensuring that the connection is secure.
The web server does not necessarily need to be a dedicated server for the policy file, as long as it can serve the file at the required path and over HTTPS. Many organizations simply add a virtual host configuration to an existing web server. Remember, the content-type for an MTA-STS policy file should typically be text/plain.
Ensuring proper policy retrieval
The key is that the policy must be reachable and return an HTTP status code of 200 (OK) when requested by a mail server. If the file is not found, or what happens if an MTA-STS policy file is not found is that the requesting MTA will defer to its existing (and potentially less secure) email delivery mechanisms.
For detailed instructions on configuring a web server, you can refer to resources like Microsoft's documentation on enhancing mail flow with MTA-STS, which often provides guidance relevant to server setup.
The MTA-STS policy file’s contents
Contents of the policy file
Once you have the correct directory path and a secure web server setup, the next step is to create the actual MTA-STS policy file itself. This text file contains key-value pairs that define your domain's MTA-STS policy. These fields instruct sending MTAs on how to handle email connections to your domain. Here's an example of what it looks like:
Each field plays a specific role in securing your email. For instance, the version field indicates the policy syntax, while the mode field sets whether the policy is in testing, enforce, or none mode. The mx field lists the valid MX hosts for your domain that support TLS.
The max_age field defines how long the policy should be cached by sending MTAs, in seconds. This ensures that even if your web server goes down temporarily, sending servers will still have a recent copy of your policy. It's crucial to detect and verify MTA-STS policy changes to ensure continuous protection.
Monitoring and management
Monitoring and management
Beyond the initial setup, continuous monitoring of your MTA-STS policy, along with other email authentication protocols like DMARC, SPF, and DKIM, is essential. This helps ensure that your policy remains discoverable and correctly enforced, and that your email deliverability is not negatively impacted by configuration issues or other factors that could lead to your emails being marked as spam or blocked (or blacklisted).
Platforms like Suped offer comprehensive DMARC reporting and monitoring, which includes insights into MTA-STS performance and potential issues. With AI-powered recommendations, Suped helps identify and resolve problems quickly, strengthening your email security posture and improving overall deliverability. This unified approach streamlines management for all email authentication protocols.
Real-time alerts notify you of any changes or failures in your MTA-STS policy retrieval, allowing you to react swiftly. For businesses and Managed Service Providers (MSPs) managing multiple domains, a unified dashboard provides a single, clean interface to oversee all aspects of email security and deliverability. This proactive management is key to maintaining trust and ensuring your messages reach their intended recipients without interruption.
Conclusion
Final thoughts on secure policy hosting
The directory path for your MTA-STS policy file is a critical element of your email security infrastructure. By hosting the mta-sts.txt file at https://mta-sts.your-domain.com/.well-known/mta-sts.txt, you create a trustworthy and discoverable endpoint for sending MTAs to retrieve your domain's TLS policy. This specific, standardized path is fundamental to preventing downgrade attacks and ensuring the secure transmission of your email.
Implementing MTA-STS correctly is a vital step in modern email authentication, working alongside DMARC, SPF, and DKIM to create a robust defense against various forms of email fraud and interception. It adds another layer of security, ensuring that sensitive information remains protected during transit.
As email threats continue to evolve, adhering to best practices for protocols like MTA-STS is more important than ever. Regularly reviewing and validating your configurations will help maintain the integrity and deliverability of your email communications.
