Mail Transfer Agent Strict Transport Security (MTA-STS) is a security standard that helps protect your incoming email from man-in-the-middle and downgrade attacks. It works by allowing you to publish a policy that tells sending mail servers they must use an encrypted TLS connection when delivering email to your domain. A key part of this policy is the max_age parameter. This directive specifies, in seconds, how long a sending server should cache your MTA-STS policy. Getting this value right is a balance between performance and agility.
The max_age value essentially tells other servers, "You can rely on this policy for this amount of time before you need to check for an updated version." This caching mechanism is crucial for efficiency, as it prevents sending servers from having to look up your policy every single time they want to send you an email. The official RFC 8461 specification outlines how this works in detail. But what is the right value to choose?
Starting with 'testing' mode
When you first implement MTA-STS, you should always start with the mode set to testing. This allows you to receive TLS reports about potential policy failures without actually blocking any emails. During this phase, it is wise to use a relatively short max_age.
A common recommendation for the testing phase is 86400 seconds (24 hours). This value is long enough to be respected by sending servers but short enough that if you discover an issue with your configuration, you can deploy a fix that will be picked up within a day. Some sources note that using a value less than 24 hours might cause some senders to ignore it, so 86400 is a safe starting point.
Moving to 'enforce' mode
Once you have monitored your TLS reports, are confident that your configuration is correct, and see no issues, you can move your policy mode to enforce. At this point, you should also increase the max_age to a much larger value. This improves efficiency by reducing the number of times sending servers need to fetch your policy.
- A good middle ground: 604800 (1 week) or 1209600 (2 weeks) are very common and sensible values. This provides a strong balance between performance and the ability to update your policy in a reasonable timeframe if needed.
- A longer duration: You can opt for a much longer period, such as 2592000 (30 days). The maximum allowed value is 31557600 (about 1 year). A longer duration is more efficient but means that any changes to your MX records or TLS certificates will take longer to propagate to all sending servers.
Final recommendations
Choosing the right max_age is about finding the sweet spot for your organization. For most, a phased approach is best.
My recommendation is to start with a max_age of 86400 (1 day) while your policy is in testing mode. After you have verified that everything is working correctly and are ready to switch to enforce mode, increase the max_age to at least 604800 (1 week). This provides a good default that balances security, performance, and administrative flexibility.
Remember, every time you update your MTA-STS policy file, you should also update the id field in your DNS record. This signals to sending servers that a new policy is available and that they should fetch it, regardless of the current max_age they have cached.
