In setting up SMTP MTA Strict Transport Security (RFC 8461) for my domain, I've noticed some contradictory advice and practice: although the maximum value for the max_age policy value is around one year and the RFC states that "implementers SHOULD prefer policy "max_age" values to be as long as is practical" to mitigate MITM attacks, most of the policies I've found in the wild use relatively short values, such as Gmail (one day), Outlook (one week), or the UK National Cyber Security Centre (two weeks). The longest value I've found in the wild is Soverin's, at approximately four months. The standard recommendation online seems to be "at least one or two weeks" and vague or no indication about a recommended value above that (e.g. Mailhardener, OnDMARC, NCSC), which seems short compared to the 1-2 years frequently used with HTTP Strict Transport Security.

My understanding is that as the policy is supposed to be refreshed on a regular basis, the _mta-sts record is used to signal updates, and you can always manually override a policy as long as you retain control of the domain (including to explicitly disable MTA-STS), the only realistic risk of a long max_age is that if you become unable to serve the policies over DNS/HTTPS for the long term, you can't disable MTA-STS. (But presumably at that point you have other problems, as it implies you've lost control over your domain? Indeed, the RFC explicitly says that the none mode is there to allow recovery after compromise by an attacker publishing an unwanted policy with a long max_age.)

The only failure mode worse than this I can imagine is if your SMTP TLS is broken or you need to update your MX records, and a sending MTA doesn't follow the SHOULD recommendation to refresh the policy around once per day; then you could have deliverability issues until your old policy expires. But this involves a sender ignoring the RFC best practices and not even bothering to check a single DNS TXT value for updates, even though they have to check the MX regardless; in fact, it's unclear to me from the RFC whether not checking the _mta-sts record when delivering mail is compliant, even if you don't proactively refresh policies at other times.

So if you're the kind of person to use a 1-2 year max-age for your HSTS headers and add your domain to the preload list, are there any practical downsides to using an MTA-STS max_age value in the months to a year range?

1 Answer 1


First and foremost: I don't know the exact reasons as to why the sites you have found have choosen their max_age values in those ranges. That said, we can hypothesize possible reasons. It is up to you to decide whether they apply to your use case as well.

  • Large email providers are often worried about compatibility. In my experience, in email you tend to have a really large ecosystem with lots of different implementations. Standard behaviour is more often violated than not, still correct mail delivery is of importance. Therefore, changes that have a breaking potential are made very carefully and slowly by providers.

    A small max_age might prevent issues with implementations that do not refresh at all. Not refreshing is not a violation of RFC 8461, as Section 3.3 states:

    Finally, to mitigate the risk of persistent interference with policy refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively refresh cached policies before they expire; a suggested refresh frequency is once per day.

    A similar statement is repeated in section 10.2. Hence, the policy refresh is intended to mitigiate attacks. It is not intended to prevent actual interopability causes that occur as a result of using outdated MTA-STS policies (such as a major version change perhaps).

  • A small max_age value allows for much easier MTA-STS removal or changes, if interoperability problems are detected. This might also apply for large integrators that do not yet support MTA-STS, but will in the future. This may cause existing MTA-STS providers to retroactively change their MTA-STS, which is much easier if you do not have to rely on clients doing the proper refresh.

  • With HTTP Strict Transport Security (HSTS), we also started out with really small lifetimes. Those were increased over time, as stability and interoperability tests were good. For example, in 2010 the Wikipedia article on HSTS suggested a max-age of only 500 seconds. It is possible that we're seeing the exact same "slow ramp up" as with HSTS, but perhaps email technology is slower at adoption.

  • A long max_age might also have the negative side effect that it encourages non-refreshing behaviour. For HSTS this never was an issue, as the HSTS is being signalled on most (if not all) site visits. With MTA-STS, we have this out of band mechanism that may not be well understood everywhere. A long max_age might suggest that implementations are supposed to use long refresh intervals (if any). This in turn can be problematic, if legitimate changes to the policy are needed. And while RFC 8461 states that MTA-STS lookups must be done if cached policy validation fails*, again providers may be cautious playing with unknown scenarios.

  • Finally, this may also be related to the bandwagon effect: IT departments deploying MTA-STS might validate their deployment by comparing with others, just like you have apparently done. If all of them use small max_age values, this may incline them to do the same.

    [*]: RFC 8461 Section 5.1:

A message delivery attempt MUST NOT be permanently failed until the sender has first checked for the presence of a new policy (as indicated by the "id" field in the "_mta-sts" TXT record).

  • 1
    Thank you for the thoughtful answer. I missed that MUST NOT from the RFC; it seems like my worst-case worry doesn't apply. Relying on SHOULDs makes me a little uneasy but I'm happy to rely on MUSTs. It seems like the biggest risk of a long-lived policy is something like "if your mail server's TLS and a sender's DNS are compromised and they ignore the SHOULD then they may deliver mail to the compromised server until policy expiry, even after you move your MX". That seems like a fairly far-fetched scenario and reassures me that the risks of long max_age values are relatively minor.
    – Emily
    Commented Jun 14, 2023 at 19:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .