Advanced MTA-STS: edge cases, scale, and monitoring

This guide assumes MTA-STS is already deployed and passing. It covers what breaks at scale and how mature teams operate it.

Edge cases that break a working setup#

• Listing MX hostnames that do not exactly match certificate names.
• Forgetting to bump the id when the policy file changes, so caches never refresh.
• Mail forwarded through mailing lists or personal forwarders, which alters headers and content.
• Acquisitions and rebrands that introduce domains nobody audited.
• Vendors silently changing their sending infrastructure.

Operating it as infrastructure#

1. Assign an owner for each sending domain and each vendor relationship.
2. Put DNS records under version control or a change-review process.
3. Alert on authentication pass rate drops and reputation changes, not just outages.
4. Run a quarterly audit against the setup steps below.
5. Document runbooks for the three most common failures.

Reference: the baseline setup#

1. Publish a _mta-sts TXT record with an id value you will change on each policy update.
2. Host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing your MX hosts.
3. Start in mode: testing, then move to mode: enforce after reviewing TLS-RPT reports.
4. Publish _smtp._tls TXT with rua=mailto: to receive TLS-RPT reports.

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: *.googlemail.com
max_age: 604800

Frequently asked questions#