max_age is a commitment, not a hint. A sender holding your policy will refuse hosts it does not list for the full duration, so every change has to lead the MX change by at least that long.
Adding an MX host
T-0 add the new host to the policy file
bump id in the TXT record
(the MX record is NOT touched)
T+max_age every sender has refetched. Confirm from TLS-RPT
that no failures reference the new host.
T+max_age now add the host to the MX record.Doing it in the other order means senders with a cached policy connect to a host the policy does not permit and refuse to deliver. Under enforce that is a deferral, and a long enough one becomes a bounce.
Removing one
The reverse, and easier: take it out of the MX record first, leave it in the policy until the cached copies have aged out, then remove it from the policy. A host listed in the policy but absent from MX is harmless.
| Change | Policy first, or MX first? |
|---|---|
| Adding an MX host | Policy first, by at least max_age. |
| Removing an MX host | MX first. Policy can lag safely. |
| Changing mail providers wholesale | Both providers in the policy for a full max_age, then cut over MX, then prune. |
Moving testing to enforce | Policy only. No MX change involved. |
Choosing max_age
- Start low. 86400 during rollout means a mistake ages out in a day rather than a week.
- Raise it once stable. A longer value is stronger protection: a sender holding a week-old policy is still protected while an attacker blocks your policy host.
- Lower it before a planned migration, a full current-
max_ageperiod in advance. The same reasoning as a DNS TTL, with a much longer clock. - The maximum is a year, and nobody should use it.
Withdrawing entirely
Deleting the TXT record does not withdraw a policy — senders holding a cached copy keep enforcing it until max_age elapses. To withdraw, publish mode: none, bump the id, and leave both in place for a full max_age before removing anything.
This is the way MTA-STS takes a domain offline
A policy in enforce listing hosts that no longer exist, on a domain whose policy host has been decommissioned, is a domain that enforcing senders cannot deliver to and cannot be told otherwise. Withdraw before you decommission, in that order, with the wait in between.