MTA-STS — Enforcing Encrypted Mail Delivery
MTA-STS lets a domain declare that mail sent to it must be delivered over TLS to a named set of servers, closing off the downgrade attack that opportunistic encryption leaves open. It has two halves that must agree: a DNS record advertising the policy, and a policy file served over HTTPS at a well-known location. This checks both and compares them.
Why run it
The two-part design is exactly what makes it fragile. The DNS record can advertise a policy version that the served file no longer matches, the certificate on the policy host can expire, or the MX list in the policy can fall out of step with your actual MX records after a migration — at which point compliant senders refuse to deliver, because the whole point of the policy is that they refuse. Checking both halves together is the only way to see that they have diverged.
Why automate it
Because the failure is worse than not having the policy at all. Without MTA-STS, a delivery problem degrades to unencrypted delivery; with a broken one in enforce mode, mail is rejected outright. The most likely trigger is an MX change made by someone who did not know the policy file existed, and the second most likely is the policy host's certificate expiring. Both are invisible internally and both are caught immediately by a scheduled check that validates the pair.
What it gives you
Protection against your own security policy becoming a mail outage. MTA-STS is worth deploying, and it is only safe to deploy in enforce mode if something is continuously checking that both halves still agree.