MTA-STS glossary
What does max_age mean in an MTA-STS policy?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
max_age sets how long, in seconds, a sending server may cache your MTA-STS policy — up to a maximum of 31557600, about one year. The cached copy is what protects you between fetches: even if an attacker suppresses your DNS record, senders keep enforcing the policy they already hold until it expires.
max_age at a glance | |
|---|---|
| Tag | max_age |
| Valid values | Non-negative integer seconds, maximum 31557600 (about one year) |
| Default | Required — every MTA-STS policy file must set max_age. |
| Where it goes | One key/value line in the mta-sts.txt policy file, e.g. max_age: 1209600 |
How max_age works
When a sender fetches your policy file, it may cache the result for up to max_age seconds. On later deliveries it checks the cheap DNS record at _mta-sts.<domain>: if the id matches what it cached, it uses the cached policy without refetching the file over HTTPS.
That cache is the security, not just an optimisation. MTA-STS's weak point is discovery — an attacker who can suppress or block your DNS record could make your domain look like it has no policy at all. But a sender holding a cached policy keeps enforcing it until the cache expires, DNS attack or not. That's why RFC 8461 recommends lifetimes of weeks or longer once your setup is stable: a long cache is a long window in which you can't be downgraded.
The standard pattern: short max_age (a day or so) during rollout so mistakes age out fast, then weeks or more at steady state. And remember the companion rule — a long max_age doesn't slow your updates, because changing the policy just requires bumping the DNS id. Forget the id bump, though, and senders won't refetch until the cache expires, however long that is.
Correct record vs common mistake
Correct
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 2419200Four weeks of cache at steady state — senders keep enforcing your policy even if your DNS record is suppressed in the meantime.
Common mistake
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 300Five minutes of cache in production leaves almost no downgrade protection — an attacker who can interfere with your DNS only ever has to wait minutes for sender caches to empty.
Troubleshooting max_age
| Issue | Likely cause | Fix |
|---|---|---|
| Policy update not taking effect | Senders are inside their cache window and the DNS id wasn't bumped | Change the id in the _mta-sts TXT record — cached senders refetch on their next check |
| max_age still at the short rollout value months later | Nobody moved the domain to steady state after go-live | Raise it to weeks (1209600 or more) once your TLS-RPT reports are clean |
| Policy rejected by validators | max_age missing, non-numeric, or above 31557600 | Set a plain integer number of seconds, at or below 31557600 |
Why it matters for MSPs
Cache lifetimes are where a hand-managed fleet drifts: some client domains left on the 24-hour rollout value with barely any downgrade protection, others set long with nobody bumping ids on changes. Across 50–200 tenants you end up unable to say when any policy change actually takes effect — or which domains are quietly running stale rules.
Trusted by MSPs
“All our emails started magically reaching the inbox in less than a week”
Marc-André Campagna — CEO, gaiia
DMARC software that does the work
Palisade hosts the policy file for every client domain and manages the cache lifecycle for you — a short `max_age` during rollout, weeks at steady state, and an automatic `id` bump on every change so updates land immediately instead of waiting out the cache.
1 domain free up to 1,000 emails/month
Questions readers ask