Documentary review: 8 November 2026. No domain, mail server or policy host was tested. The worksheet and scenario are proposed operational aids, not evidence of a deployed policy.
Follow the receiving route
MTA-STS concerns delivery to a receiving domain. A supporting sending mail transfer agent discovers the recipient domain's policy and checks whether the receiving mail servers satisfy it. This is different from configuring authentication for messages sent by your own application. Start with the domain after the recipient's at-sign, its published MX route and the servers that actually accept incoming mail. MTA-STS overview
For example, the team responsible for incoming mail at example.com should identify every legitimate MX destination, including a backup provider. A website hostname, an employee's submission server and the visible From address of an unrelated message do not substitute for this route inventory. Name the mailbox-service owner and the DNS owner before making a policy proposal.
The sender still discovers destinations through MX. The MTA-STS policy constrains acceptable destinations and TLS behavior; it is not a replacement list that redirects mail to a different service. Adding a hostname to the policy does not create an MX record, provision a mailbox or make a server accept the domain. Those service responsibilities remain separate.
Separate discovery from policy content
The discovery record is a TXT record at _mta-sts.example.com for the example.com receiving domain. Its version identifies STSv1 and its id allows senders to notice policy changes. The id is not the policy itself and does not encode a certificate or MX list. Keep the complete DNS value and the corresponding policy revision together in the change record. Policy discovery
The policy is retrieved from https://mta-sts.example.com/.well-known/mta-sts.txt. The receiving domain determines this location. Do not replace it with a URL chosen by the mailbox provider merely because that provider hosts the MX servers. A supported hosting arrangement must still serve the required domain and path with the required HTTPS authentication.
The policy text identifies STSv1, a mode, permitted MX patterns and max_age. The sending system processes these fields according to the standard. An arbitrary web page, a JSON configuration file or a DNS TXT record containing the entire policy is not the same format. Preserve an exact reviewable policy artifact before publishing anything.
Match MX patterns to the actual service
For testing and enforce policies, list the legitimate receiving MX hostnames or appropriately bounded wildcard patterns. Match the MX hostname, not the recipient address, the IP address or a web certificate's unrelated name. A wildcard is permitted only as the complete leftmost label and matches one label, so *.example.net is not a general authorization for every deeper name beneath example.net. MX matching
Use the narrowest accurate inventory. A broad pattern may make future changes easier, but it also admits more hosts within the pattern. An exact list may be clearer when a service publishes a small stable set. Confirm the provider's supported receiving names rather than deriving policy entries from a transient banner or an assumed brand hostname.
The receiving server must offer STARTTLS and present a certificate that satisfies the standard's validation requirements, including the relevant MX hostname. A policy match alone does not prove that the certificate is valid, trusted or currently within its validity period. Conversely, a good certificate for a server omitted from the policy does not make that server policy-compliant.
Choose a mode based on evidence
The testing mode permits observation without instructing supporting senders to block delivery because of policy validation failure. Enforce asks supporting senders to deliver only when the policy's requirements are satisfied. None signals that the domain is not implementing MTA-STS. These modes are operational decisions, not measures of how confident an administrator feels about the editor screen. Policy modes and application
Before proposing enforce, assess every legitimate incoming path, including fallback destinations and certificate renewal. An untested backup MX can turn an otherwise recoverable provider outage into a delivery problem when a sender correctly applies the cached policy. Do not regard a successful delivery to the preferred MX as acceptance for the entire route.
When delivery fails because of an enforce policy, a compliant sender MUST NOT permanently fail delivery before checking DNS for an updated policy. RFC 8461 says senders SHOULD treat these failures as transient and retry later. Enforcement therefore must not be described as an instruction to bounce immediately on the first mismatch. Policy application
MTA-STS does not guarantee universal adoption by all sending systems. Nor does it establish SPF, DKIM or DMARC success for the message. Its purpose is protection of the SMTP transport route against particular downgrade and interception risks. Keep transport observations separate from message-authentication results and mailbox spam-placement decisions.
Account for cached policy
A sender can cache a valid policy for the max_age interval. Changing DNS or deleting the HTTPS file does not instantly erase policies already held by other systems. A migration must therefore preserve compatibility with previously published valid policies while the relevant caches can remain in use. Record the previous policy and its lifetime, not only the new file. Policy caching
The discovery id helps a sender recognize a changed policy and obtain an update, but it is not a remote cache-purge command. Publish a coherent policy change and corresponding discovery update through a reviewed sequence. Do not promise that every sender will fetch at the same moment or observe an emergency edit immediately.
A safe receiving-provider migration normally requires an overlap plan: identify old and new legitimate destinations, evaluate their TLS behavior and consider the cached old policy before changing MX. The exact sequence depends on the service transition. This guide supplies decision points rather than an unverified tenant-specific deployment recipe.
Use reporting as supporting evidence
TLS reporting is specified separately from MTA-STS. A TLS-RPT TXT record at _smtp._tls.example.com can request aggregate reports at approved destinations. Reports can help identify policy or TLS failures, but they are not guaranteed to arrive from every sender and do not replace direct route acceptance tests. TLS reporting
Agree who monitors reports and who can investigate certificate, MX and policy-host failures. Protect report access and avoid interpreting a quiet reporting period as proof that all senders tested all backup routes. The evidence should state its coverage and time range.
Receiving-route acceptance worksheet
- Receiving domain and business owner: ___.
- Current MX answers, priorities and authoritative timestamps: ___.
- Each legitimate destination, service owner and fallback purpose: ___.
- Policy patterns and exact matching rationale: ___.
- STARTTLS and certificate evidence for each destination: pending.
- Discovery TXT, policy artifact, revision id and HTTPS result: pending.
- Mode, max_age and previous cached-policy compatibility: ___.
- TLS-RPT destination approval and monitoring owner: ___.
- Controlled delivery results, recovery plan and final sign-off: pending.
Fictional example: the omitted fallback
This case is fictional. A domain publishes two MX hosts but its proposed enforce policy names only the preferred host. Routine test mail succeeds there. During a maintenance exercise the backup becomes the relevant destination, and a supporting sender cannot accept it under the policy even though the backup has a valid certificate.
The team reviews the full route rather than weakening unrelated message authentication. It plans a policy that accurately includes approved receiving hosts, verifies the backup's TLS behavior and assesses the lifetime of the previously cached policy before changing production. No such test occurred for this manuscript. Live DNS, delivery evidence, visual review and accountable release remain explicit outstanding gates.