Documentary review: 8 November 2026. No HTTPS deployment, DNS edit or live policy fetch was performed. This guide describes a proposed publication and verification procedure; its example is fictional.
Fix the URL before selecting hosting
For a receiving domain example.com, the MTA-STS policy location is https://mta-sts.example.com/.well-known/mta-sts.txt. The HTTPS service uses port 443. The path, hostname and scheme are part of the protocol, not branding choices. A working file at www.example.com, an object-storage vendor URL or a mailbox provider's documentation page is not the required endpoint. Policy fetching
Select hosting that can serve that exact hostname and path with a publicly trusted certificate valid for the policy hostname. A DNS alias can help reach an implementation, but the hosting service must still recognize the requested custom hostname. DNS resolution alone does not establish certificate validity or successful HTTP service.
Keep the receiving domain separate from its MX provider. The policy host belongs to the recipient-domain discovery process, even when another company receives the mail. Record who owns the custom-domain binding, certificate renewal, content publication and DNS reference. A hosting account without a responsible renewal owner is an incomplete plan.
Serve the policy directly
RFC 8461 requires policy retrieval over authenticated HTTPS and forbids following HTTP redirects. Serve the file directly at the required URL rather than relying on a redirect from an apex site, a login page, a regional endpoint or a canonicalized path. An ordinary browser may follow a redirect and display the text while concealing a protocol problem. The acceptance evidence must preserve the original response. HTTPS policy authentication
A web application firewall, access challenge or authentication gate can similarly return something other than the policy. Check that the endpoint returns the intended policy content to an unauthenticated sender-facing request. Do not depend on cookies, browser sessions or an administrator's IP allowlist to make the acceptance test pass.
The fetch must return HTTP 200. RFC 8461 says senders SHOULD validate the text/plain media type; publish that type rather than relying on a sender to tolerate something else. Preserve status, content type and exact body together. A human-readable HTML page containing a policy example is not equivalent to the policy file. A deployment's generic health endpoint is also insufficient because it may succeed while the .well-known route is missing.
Prepare an exact policy artifact
The policy has a line-oriented format with version, mode, mx and max_age fields. Use STSv1 as the version value. Testing and enforce policies identify acceptable MX patterns; none has different semantics. Validate the proposed document against the standard before treating the host as ready. Policy syntax
Choose MX values from the actual receiving route. Exact names and the permitted leftmost-label wildcard have defined matching rules. Do not use a URL, email address or arbitrary substring expression in place of an MX pattern. A successful HTTPS fetch cannot compensate for a policy that excludes a legitimate receiving server.
Set max_age as the intended policy-cache lifetime in seconds within the standard's limits. It is not the HTTPS object's browser cache header or the DNS record's TTL. Record the reason for the selected lifetime and the operational commitment to keep receiving infrastructure compatible with cached policies.
Store the exact reviewed content, a revision identifier and an integrity hash in the change record. This makes it possible to compare the approved artifact with the served body. It also prevents an editor's line wrapping or a templating layer from silently changing what was approved. The hash is internal acceptance evidence, not a new field to insert into the MTA-STS policy.
Coordinate DNS discovery and publication
The TXT discovery record lives at _mta-sts.example.com and includes the STSv1 version and a policy id. The id signals policy changes; it is not a secret, a signature or the policy body. Keep the DNS revision linked to the intended HTTPS artifact so an operator can explain which content a discovery update was meant to announce. Discovery record
Before introducing a policy, establish the correct host, certificate and content path, then perform the approved discovery publication and acceptance checks. For an update, prepare and validate the new artifact before announcing its new id. Account for old and new states during the transition rather than assuming publication across DNS and hosting is atomic.
Sending MTAs MUST NOT use HTTP caching when fetching policies over HTTPS. This is distinct from retaining a validated MTA-STS policy under its max_age. RFC 8461 also discusses reverse-proxy caching as a separate hosting concern; an HTTP Cache-Control header does not replace the policy-cache rules. Hosting and caching distinctions
A deployment tool may update files globally at different times or retain old objects in a cache. This guide does not assert any vendor's consistency behavior. Ask the selected host's owner to document the relevant deployment and rollback properties, then collect responses from appropriate external vantage points. Do not label one successful request proof of worldwide consistency.
Distinguish HTTPS failure from SMTP failure
The policy HTTPS certificate authenticates the policy host. The SMTP certificate is presented by an MX server during mail delivery. They are different endpoints with different names, owners and renewal processes. Testing the website certificate does not prove that an MX server offers valid STARTTLS, and a good MX certificate does not repair a broken policy-host certificate. Policy and MX validation
Use stage-specific evidence. A DNS error affects finding the host. A certificate validation error affects authenticating HTTPS. A redirect or missing file affects retrieval. A malformed body affects policy parsing. An excluded MX or invalid receiving certificate affects delivery under the policy. Assign each failure to the responsible team before editing unrelated records.
The sending system's cached policy also matters. A current fetch failure does not mean that all supporting senders immediately forget an earlier valid policy. Deleting the file is not a universal disable switch. Recovery must consider previous max_age values and the standard's cached-policy behavior, with no promise of instant global reversal.
Plan maintenance and retirement explicitly
Certificate expiry, custom-domain binding changes and accidental routing rewrites can break a policy endpoint without changing its TXT discovery record. Include the exact policy URL in monitoring and deployment acceptance, rather than monitoring only the site's root page. Retain a last-known approved artifact and identify who can restore it through the authorized hosting process.
If retiring MTA-STS, review the standard's none mode and cached-policy implications instead of simply deleting DNS and the file. The appropriate transition depends on what senders may still hold. Record the retirement plan and maintain the necessary endpoint availability while the approved transition completes. Policy updates and caching
TLS reports can supplement monitoring of transport-policy failures where participating senders provide them. They do not guarantee detection of every HTTPS hosting fault. Keep direct endpoint verification and report review as distinct signals. TLS reporting
HTTPS publication acceptance worksheet
- Receiving domain and exact required URL: ___.
- DNS authority, hosting account and custom-domain owner: ___.
- Certificate name, trust, validity and renewal responsibility: pending.
- Original HTTP status, redirect absence and text/plain result: pending.
- Approved artifact hash and returned-body comparison: pending.
- Mode, MX matches, max_age and syntax review: ___.
- Discovery TXT id and linked artifact revision: ___.
- Prior cached-policy compatibility and rollback decision: ___.
- External fetch evidence, mail-route tests and owner sign-off: pending.
Fictional example: a helpful redirect that breaks retrieval
This example is fictional. A team publishes the policy under a static site's download directory and redirects the required .well-known URL there. An administrator's browser follows the redirect and displays correct text, so the initial review calls the endpoint healthy.
The proposed protocol-aware review records the original redirect response and rejects it as acceptance evidence. The hosting owner plans to serve the approved text directly at the required path, verifies the hostname certificate and preserves the direct response with the content hash. The team then separately checks the receiving route and cached-policy transition. No deployment occurred here. Operational evidence, visual review and owner release remain pending for this draft.