DIAGNOSTIC PLAYBOOK
MTA-STS changes are not immediate: understand policy caching
Supporting senders can cache an MTA-STS policy for its max_age period. A current web file does not necessarily describe the policy a sender used for an earlier or ongoing delivery attempt.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Save the current and previous policy contents, identifiers and publication times.
- Compare the failure time with the lifetime of previously published policy data.
- Keep transition-compatible MX and certificate behavior while relevant cached policies may remain valid.
What this looks like
ILLUSTRATIVE EXAMPLE
An administrator removes an old MX from the policy before all senders refresh. Different senders temporarily evaluate delivery against different policy versions.
A mistake to avoid
Do not assume deleting the TXT record instantly cancels an existing cached policy. Use a planned policy transition.
Keep the result in context
Transport encryption protects a connection between mail systems. It is different from message authentication and does not imply end-to-end encryption. Investigate the receiving MX hostname, the TLS session and the applicable policy separately before deciding which system needs a change.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.