MTA-STS changes a sending server's delivery decision
MTA-STS lets a receiving domain publish a policy for supported SMTP senders to apply when delivering mail. Its policy discovery uses DNS and HTTPS, while the actual mail delivery still goes to the domain's MX hosts. A working policy website is therefore not proof that every advertised mail endpoint satisfies the policy.
For beginners, separate transport protection from spam filtering and message authentication. MTA-STS does not replace SPF, DKIM or DMARC. This guide covers a cautious receiving-domain rollout with sender caching in mind, not a claim that every sender implements the policy.
Setup: inventory every legitimate receiving path
Record the current MX hosts, planned migration targets, their TLS certificates and the owner of the policy HTTPS service. Identify continuity and disaster-recovery paths that may be used during an incident. A policy that lists only the normal primary path can interfere with an otherwise legitimate recovery arrangement.
An illustrative discovery and policy relationship is:
_mta-sts.example.test TXT: v=STSv1; id=reviewed-policy-01
HTTPS: https://mta-sts.example.test/.well-known/mta-sts.txt
The HTTPS policy needs the required version, mode, MX patterns and max_age fields with values appropriate to the real domain. The example is not a deployable policy and deliberately does not invent the organization's mail hosts or enforcement duration.
Illustrative incident: a migration forgets the cached policy
In this fictional example, a domain changes its MX host during a mail-platform migration. The published policy still permits only the former host, and some senders retain an earlier policy while others discover the change. Different delivery behavior appears even though everyone sees the new MX record.
The team compares the old and new policy, DNS identifier, cache duration and transition plan. It prepares compatibility through the migration period instead of assuming a DNS edit immediately replaces every sender's cached delivery rules.
Troubleshooting: test discovery and mail transport separately
| Observation | Evidence | Boundary |
|---|---|---|
| Policy cannot be fetched | HTTPS hostname, certificate, path and response | Policy distribution service |
| New MX is not accepted by the policy | Published MX patterns and actual DNS | Receiving-path inventory |
| Senders behave differently after a change | Policy identifiers and cache timelines | Previously cached versus refreshed policy |
| Policy website works but mail TLS fails | Certificate and TLS behavior on the MX hosts | SMTP delivery endpoint |
Do not use the HTTPS policy server's certificate as evidence about the SMTP server's certificate. Likewise, a policy syntax check does not test the network path or certificates of all MX endpoints. Keep a timestamped matrix of the discovery and transport checks.
Move from observation to enforcement deliberately
Use a testing phase and appropriate transport reports or controlled delivery tests to identify mismatches before enforcement. Review policy updates and their cache implications with the mail and DNS owners. Choose max_age to fit a staged rollout and operational ability to maintain the receiving paths.
An emergency policy change is not guaranteed to invalidate an already cached policy instantly. Plan rollback and MX transitions before enforcing a long-lived policy. If the organization's recovery mail path differs, include its requirements in the design rather than weakening TLS checks reactively during an outage.
Verification, monitoring and SOP
Verify the DNS policy identifier, HTTPS policy contents and TLS identity of every intended MX path. Use approved sender tests and review transport-failure reports where available. Confirm ordinary mail flow continues, while keeping authentication and deliverability investigations as separate workstreams.
An internal SLO can describe valid policy availability and supported MX transport readiness; an external email SLA needs explicit sender and platform assumptions. The SOP should record policy owners, complete MX inventory, testing evidence, cache-aware change sequence, certificate renewal, rollback limitations and the process for adding a new receiving endpoint.
See Clouvenix email security for a reviewed implementation and operational handover.
Technical reference
IETF SMTP MTA Strict Transport Security specification. Reviewed 19 October 2026; use documentation for the installed product and release.