What is the recommended 'max_age' for an MTA-STS policy?
Matthew Whittaker
Co-founder & CTO, Suped
Published 24 Jul 2025
Updated 30 Oct 2025
7 min read
The 'max_age' parameter is a crucial component within an MTA-STS policy, dictating how long a sending mail server should cache and enforce your domain's policy. This value is specified in seconds and plays a significant role in both the security and flexibility of your email transport. Choosing the right 'max_age' is a balance between ensuring robust security and allowing for timely policy updates.
When a sending server first discovers your MTA-STS policy, it will download and cache the policy for the duration specified by 'max_age'. During this period, all subsequent connections to your domain will strictly adhere to the rules outlined in that policy, such as requiring TLS and matching MX records. This caching mechanism is fundamental to how MTA-STS prevents downgrade attacks and ensures encrypted mail delivery.
Therefore, the recommended 'max_age' isn't a one-size-fits-all number. It depends heavily on your deployment stage, operational stability, and tolerance for potential disruption during policy changes. Understanding the implications of different 'max_age' values is key to a successful MTA-STS implementation.
What is the recommended 'max_age' for an MTA-STS policy?
Understanding the 'max_age' parameter
The 'max_age' field in your MTA-STS policy file specifies the maximum time (in seconds) that a compliant mail transfer agent (MTA) should remember and enforce your domain's MTA-STS policy. This value directly influences how quickly changes to your policy, such as updates to MX records or certificate information, will propagate across the internet. A longer 'max_age' provides greater resilience against attacks, as the cached policy remains active for an extended period, but it also means less flexibility for rapid adjustments.
According to official guidelines, the 'max_age' value must fall between 86400 seconds (1 day) and 31557600 seconds (approximately 1 year). This range allows administrators to choose a duration that aligns with their operational needs. For instance, a very short 'max_age' would make policy changes take effect quickly, which is beneficial during initial testing phases. Conversely, a very long 'max_age' would ensure that once a policy is adopted, it remains enforced for a significant period, reducing the frequency of policy fetches.
The primary purpose of 'max_age' is to enhance the security posture of your email communications. By caching the policy, sending MTAs can continue to enforce TLS encryption even if there are temporary issues accessing your MTA-STS policy file. This prevents adversaries from exploiting intermittent unavailability to downgrade connections to insecure plain text. For more details on the policy file, refer to our guide on the format of the MTA-STS policy file.
Max_age recommendations for different modes
Recommended values based on deployment mode
The recommended 'max_age' largely depends on the current 'mode' of your MTA-STS policy. During the initial deployment, when your policy is in testing mode, it's generally advisable to use a shorter 'max_age'. Both Google and Microsoft suggest a 'max_age' of 1-2 weeks (e.g., 604800 to 1209600 seconds) for testing. This allows for quick iteration and correction of any issues discovered during monitoring without prolonged impact on mail flow.
Once you have verified that your MTA-STS policy is working correctly and no issues are reported, you can transition to enforce mode. In this mode, a longer 'max_age' is highly recommended to maximize the security benefits. A value of 31557600 seconds (1 year) is commonly used. This ensures that sending MTAs will cache and enforce your policy for a significant duration, providing strong protection against man-in-the-middle attacks and ensuring consistent TLS encryption for your inbound emails. Be aware that changing the policy after a long max_age will require waiting for the cached policy to expire.
Example MTA-STS policy with a recommended 'max_age' for enforce modeyaml
While a longer 'max_age' enhances security, it also introduces a significant operational risk. If you set a 'max_age' of one year and then need to make an emergency change to your mail infrastructure, such as changing your primary MX records or TLS certificates, sending MTAs that have cached your policy will continue to enforce the old policy for up to one year. This can lead to email delivery failures, as incoming mail servers will attempt to connect to outdated or incorrect MX hosts, or reject connections due to certificate mismatches.
The primary realistic risk of a long 'max_age' is the inability to quickly disable MTA-STS if you are no longer able to serve your policies correctly over DNS or HTTPS for an extended period. As highlighted by Security Stack Exchange, if your policy file becomes unavailable or invalid for longer than the 'max_age', other MTAs will eventually stop enforcing your policy, effectively reverting to a less secure state. However, during the caching period, any non-compliance will result in delivery failures.
Short max_age (e.g., 1-2 weeks)
Flexibility: Allows for rapid updates to MX records or TLS certificates without extended disruption.
Testing: Ideal for initial deployment in testing or 'enforce' (report-only) modes.
Higher Overhead: Requires more frequent fetches by sending MTAs, potentially increasing server load slightly.
Long max_age (e.g., 1 year)
Enhanced Security: Provides prolonged protection against attacks once the policy is widely cached.
Operational Rigidity: Emergency infrastructure changes can cause significant email delivery issues until the policy expires.
Cool-down Period: If MTA-STS needs to be disabled, the cool-down period will be equal to the 'max_age'.
Considerations for policy changes
Monitoring and policy management
Regardless of the 'max_age' you choose, continuous monitoring of your MTA-STS policy is essential. This includes verifying the policy's availability, ensuring its content remains accurate, and observing any changes in mail flow or deliverability. Tools that provide visibility into your MTA-STS status can help you detect issues proactively and respond before they impact your email communications. For guidance on verifying policies, check our article on how to detect and verify MTA-STS policy changes.
For domains with critical email infrastructure, choosing a longer 'max_age' in enforce mode offers the highest level of protection. However, this choice must be accompanied by a robust change management process for your email systems. Any planned changes to MX records or TLS certificates should be carefully coordinated, ensuring that the MTA-STS policy is updated well in advance of the infrastructure changes, and that the previous 'max_age' has expired.
Platforms like Suped provide comprehensive DMARC monitoring which includes insights into MTA-STS, helping you track policy adherence and identify potential issues quickly. Our AI-powered recommendations can guide you in optimizing your 'max_age' and other policy fields, ensuring your email authentication is both secure and effective.
Optimal 'max_age' for long-term security
Best practices for 'max_age'
For most organizations operating a stable email infrastructure, the recommended 'max_age' for a production MTA-STS policy in 'enforce' mode is typically one year (31557600 seconds). This provides a strong security posture by maximizing the caching period for compliant MTAs, ensuring that your policy is consistently applied for the longest possible duration without requiring frequent fetches. This approach minimizes the risk of opportunistic downgrade attacks and enhances the overall trustworthiness of your domain's email. Remember, for the minimum recommended 'max_age', it's typically one day.
However, if your organization frequently makes changes to its email routing or TLS certificate configurations, you might consider a slightly shorter 'max_age', such as six months. This offers a balance between security and agility, reducing the window of potential disruption from unforeseen infrastructure changes. Always prioritize stability and thorough testing before committing to a long 'max_age' in 'enforce' mode.
Conclusion
The recommended 'max_age' for an MTA-STS policy evolves with your deployment stage and operational stability. Starting with a shorter 'max_age' during testing (1-2 weeks) allows for flexibility and quick corrections. Once confident in your policy and infrastructure, adopting a longer 'max_age' (up to 1 year) in 'enforce' mode provides the strongest security benefits. Always ensure that you have robust monitoring in place to quickly detect and address any issues, minimizing the potential impact of this crucial policy parameter.
