DIAGNOSTIC PLAYBOOK
MTA-STS policy does not cover the current MX servers
An enforcing MTA-STS policy can prevent supporting senders from delivering to an MX hostname that is not covered by the policy. MX and policy updates therefore need coordinated rollout.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Compare every live MX hostname with the policy's mx patterns.
- Determine whether senders may still hold an older valid cached policy.
- Publish overlapping coverage before a planned MX transition and verify policy discovery and endpoint health.
What this looks like
ILLUSTRATIVE EXAMPLE
The receiving provider changes from old-mail.example to new-mail.example, but the cached policy only permits the old hostname.
A mistake to avoid
Changing DNS alone is insufficient when a sender has a valid cached policy. Plan for the policy's lifetime as well as DNS TTL.
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.