What happens if I set my 'max_age' to a very low value, like 1 day?

Setting max_age to 1 day (86,400 seconds) is generally only recommended for initial testing or during periods of planned infrastructure changes. A very low value means sending MTAs will fetch your policy frequently. While this allows for quick updates, it also reduces the overall security benefit by increasing the window of vulnerability to downgrade attacks if an attacker can intercept the policy discovery process.

Can I set 'max_age' to zero to disable MTA-STS?

Setting max_age to 0 seconds is not the correct way to disable MTA-STS. To effectively disable it, you should remove the MTA-STS DNS TXT record or change the policy mode to 'none' . Setting it to 0 seconds essentially tells sending MTAs to not cache the policy, but they will still attempt to fetch it regularly.

How does 'max_age' impact email deliverability?

A well-configured max_age helps improve email deliverability by ensuring that emails are always sent over secure, encrypted connections. This reduces the likelihood of emails being marked as suspicious or rejected by receiving servers due to insecure transport. However, an incorrectly high max_age combined with infrastructure changes could temporarily disrupt mail flow if receiving MTAs are caching an outdated policy, leading to rejected emails. Tools like Suped can monitor these issues.

What is the recommended 'max_age' after a successful transition from 'testing' to 'enforce' mode?

After a successful transition to 'enforce' mode and confirmation of stable mail flow, it's recommended to increase your max_age to a value between 1 and 3 months (2,592,000 to 7,776,000 seconds). This duration offers a strong balance of security and reasonable flexibility for future administrative changes.

What is the minimum recommended 'max_age' for an MTA-STS policy? - MTA-STS - Email authentication - Knowledge base

Digital timer showing 'max_age' countdown with a padlock for email security

When configuring MTA-STS, one of the most critical parameters you'll encounter is max_age. This setting determines how long sending Mail Transfer Agents (MTAs) should cache your domain's MTA-STS policy. A properly configured max_age value is essential for maintaining strong email security and ensuring reliable mail delivery. It's a balance between quickly propagating policy changes and providing robust, long-term protection against downgrade attacks.

Understanding the 'max_age' parameter

The max_age field in your MTA-STS policy is a numerical value representing the number of seconds that a connecting mail server (MTA) should cache and enforce your policy. Once an MTA-STS enabled sending server retrieves your policy, it will remember it for the duration specified by max_age. During this period, it will only attempt to deliver mail using TLS encryption according to your defined rules. This mechanism helps prevent attackers from intercepting or altering email traffic by tricking sending servers into using unencrypted connections.

The MTA-STS standard, defined in RFC 8461, allows for a max_age value up to 31,557,600 seconds, which is equivalent to one year. This maximum value is designed to offer long-term protection, reducing the frequency with which remote MTAs need to fetch your policy. However, the optimal value is not simply the highest possible; it requires careful consideration of your email infrastructure's stability and your ability to respond to potential issues. Choosing a max_age that is too short can diminish the security benefits, while one that is too long can introduce significant administrative challenges.

The max_age parameter works in conjunction with other fields in the policy file, such as mode and mx, to define a comprehensive set of rules for secure email delivery. Understanding the interplay between these elements is crucial for a successful MTA-STS deployment. We delve deeper into all the MTA-STS policy file format and its components in our knowledge base.

Recommended values and implications

The minimum recommended max_age for an MTA-STS policy is typically **604,800 seconds**, which equates to one week. This value provides a reasonable balance, ensuring that policies are cached long enough to offer meaningful protection while still allowing for relatively quick propagation of any necessary updates or changes. For domains with stable email infrastructure and low likelihood of frequent changes to their mail servers or TLS configurations, a higher max_age is often preferable, extending up to several weeks or even months.

Setting a longer max_age provides enhanced security benefits. With a longer cache time, remote MTAs are less likely to encounter a situation where they need to re-fetch the policy, reducing exposure to potential DNS tampering or HTTP hijacking attempts that could lead to a compromise. It reinforces the expectation that your domain will consistently enforce TLS encryption for a prolonged period, making it harder for attackers to exploit transient vulnerabilities or misconfigurations. This is a key reason why many organizations opt for longer durations once they are confident in their MTA-STS setup.

Value (seconds)	Duration	Use Case / Implication
86,400	1 day	Only for initial testing (e.g., in testing mode)
604,800	1 week	Minimum recommended for enforce mode.
2,592,000	1 month	Good for stable environments, provides strong security.
7,776,000	3 months	Common choice for robust security with moderate flexibility.
31,557,600	1 year	Maximum possible, ideal for highly stable infrastructure.

When you need to make changes to your email infrastructure, such as updating MX records or TLS certificates, a shorter max_age can be beneficial during the transition. It allows remote MTAs to pick up the updated policy more quickly. However, once changes are stable, reverting to a longer max_age is recommended to maximize security benefits. Remember to always verify MTA-STS policy changes before and after deployment.

Balancing security and administrative flexibility

The choice of your max_age reflects a trade-off between maximizing security and maintaining administrative flexibility. A very long max_age value, while providing strong security, means that if you encounter an unexpected issue or need to rapidly disable MTA-STS, it could take a considerable amount of time for all sending MTAs to expire their cached policy and retrieve the new one. This could lead to temporary mail delivery issues or, in extreme cases, extended outages.

Conversely, a very short max_age (e.g., less than a week) reduces the caching effect and the protection against downgrade attacks. Sending MTAs will re-fetch the policy more often, increasing the window of vulnerability where an attacker could potentially interfere with policy discovery. The primary risk of a long max_age is the challenge in disabling MTA-STS if your domain becomes unable to serve the policies over DNS or HTTPS for an extended period, as detailed on Security Stack Exchange.

Best practice for 'max_age' transitions

Initial deployment: Start with a moderate max_age (e.g., 1 week or 604,800 seconds) in testing mode.
After stabilization: Once you confirm everything is working correctly in enforce mode, consider increasing the max_age to 1-3 months (2,592,000 to 7,776,000 seconds) for enhanced security.
Impending changes: If you anticipate major infrastructure changes, temporarily reduce the max_age to 1 day (86,400 seconds) a week or so before the change to allow faster policy updates.

The key is to proactively manage your MTA-STS policy. This includes not only setting an appropriate max_age but also ensuring that your MTA-STS policy file is consistently available and correctly configured. Regular monitoring of your email logs and DMARC reports can provide valuable insights into how your policy is being enforced by remote MTAs and if any issues arise.

Hands adjusting a 'Max Age' dial, symbolizing the careful balance in MTA-STS policy settings

Many email authentication systems, including DMARC, SPF, and DKIM, interact with MTA-STS to form a layered defense against email spoofing and phishing. A strong MTA-STS policy, supported by a carefully chosen max_age, complements these other protocols by securing the transport layer itself. This holistic approach ensures that your emails are not only authenticated at the content level but also protected during transit, significantly improving their deliverability and trustworthiness.

Maintaining your MTA-STS policy

Once you've set your initial max_age, continuous monitoring is vital. This means regularly checking the accessibility and content of your MTA-STS policy file, which is typically named mta-sts.txt. Any issues with serving this file could prevent remote MTAs from refreshing their cached policy, potentially leading to delivery failures if your infrastructure changes during the cached period. Even small changes, such as certificate renewals, need to be aligned with your MTA-STS policy. A robust DMARC monitoring solution can help you keep an eye on these authentication aspects.

For comprehensive oversight of your email security and deliverability, platforms like Suped provide invaluable support. Our AI-powered recommendations help you not just see your data, but understand exactly what actions to take to strengthen your MTA-STS, DMARC, SPF, and DKIM policies. We offer real-time alerts to notify you of any policy or deliverability issues immediately, so you can address them before they impact your email flow. This proactive approach is critical for maintaining high deliverability rates and protecting your domain reputation from potential blacklist (or blocklist) listings.

Our unified platform brings together all aspects of email authentication and deliverability, including SPF flattening, in a single, intuitive interface. For Managed Service Providers and agencies, our MSP and multi-tenancy dashboard makes it easy to manage multiple domains efficiently. With Suped's generous free plan and focus on actionable insights, we make advanced email security accessible to everyone, from small businesses to large enterprises.

Optimal 'max_age' for robust email security

Choosing the right max_age for your MTA-STS policy is more than just picking a number, it's about understanding your infrastructure and operational needs. While a minimum of one week (604,800 seconds) is recommended for active policies, aiming for a longer duration of 1 to 3 months provides a stronger security posture for stable environments. Always remember to reduce this value temporarily when anticipating changes to your mail infrastructure to allow for a smoother transition.

By carefully considering the implications of your max_age setting and actively monitoring your MTA-STS implementation, you can significantly enhance the security and deliverability of your outbound emails, ensuring they arrive securely and reliably at their intended destinations.