Documentary review: 8 November 2026. No cloud resource, repository workflow, certificate, DNS record or policy endpoint was deployed or tested. Azure Static Web Apps is the documented hosting example; the proposed acceptance process does not establish that an uninspected tenant supports every option.
Evaluate the policy service, not the serverless label
An MTA-STS policy host serves a small public document, making static hosting a plausible implementation. But serverless operation does not remove dependencies on DNS, custom-domain validation, certificates, deployment configuration or accountable maintenance. The relevant question is whether the exact required endpoint continues to serve the approved policy under normal operation and change.
For a policy domain example.com, the required location is https://mta-sts.example.com/.well-known/mta-sts.txt. RFC 8461 requires a valid HTTPS fetch with status 200, forbids following HTTP redirects and forbids use of HTTP caching by fetching senders. It recommends validating text/plain content. A default cloud hostname that works in a browser is not a substitute for the required custom hostname and certificate. MTA-STS HTTPS requirements
Treat the policy website and receiving SMTP service as separate systems. Hosting an enforce policy does not make an MX host offer STARTTLS or present a valid certificate. The content owner must first confirm the intended MX route and the matching patterns; the hosting owner must then preserve that approved document reliably.
Define a concrete Azure Static Web Apps route
For the proposed Azure implementation, keep the policy file in the repository's static-site content so the deployed output contains .well-known/mta-sts.txt at the site's root. Do not assume that a file present in the source tree survives the build. Inspect the actual deployment artifact before publication, including directories beginning with a dot and the exact lowercase path.
Azure documents GitHub Actions or Azure Pipelines as its build and deployment configuration. Its app_location identifies source content, while output_location identifies generated public files when a build runs. With skip_app_build enabled, app_location instead identifies the prepared output. Choose the settings matching the reviewed repository layout; this guide supplies no deployment credentials and performs no workflow run. Static Web Apps build configuration
Use the site's assigned deployment hostname only as the provider target, not as the published policy URL. The custom-domain procedure documents adding a subdomain through DNS and the Static Web Apps custom-domain configuration. Adapt that documented subdomain workflow to the required mta-sts hostname, using the actual resource's issued target and validation values rather than a copied example. External-provider custom domains
Check the current product variant before selecting a validation method. Microsoft's custom-domain overview states that Enterprise Grade Edge validation for new domains requires the TXT token method rather than CNAME validation. It also states that automatic certificate renewal requires the custom domain to resolve to the static web app over the public Internet. Preserve those variant and renewal dependencies in the operating record. Custom-domain validation and renewal
Keep application routing away from the policy path
A site can return HTTP 200 while serving the wrong body. Single-page application fallback can replace a missing text file with index.html; authentication rules can demand a login; canonical-host or trailing-slash settings can redirect the request. Those behaviors may be appropriate for an application but fail the policy-fetch contract.
Azure's staticwebapp.config.json controls routes, authorization, headers, MIME types and navigation fallback. Its documentation notes that route rules do not apply to requests that trigger navigationFallback. Review fallback exclusions and the actual deployed file together, rather than assuming a route rule alone protects a missing policy file from HTML fallback. Static Web Apps routing configuration
Design this endpoint for anonymous public retrieval of the approved policy, with the correct media type and no redirect or login dependency. That is an intended configuration, not evidence that an existing application is safe to expose. If sharing a site with private application content, have the application owner review the exact rule scope before any change. A dedicated minimal static site can simplify the review, but creating one remains a separate authorized deployment task.
Verify semantics as well as availability
A proposed external check should request the exact production hostname and path without following redirects. Record status, certificate validation, content type, complete body and its digest. Parse the policy fields and compare them with the approved route inventory. A homepage uptime check, a provider dashboard badge or a successful fetch of the default deployment URL cannot replace this check.
Validate MX patterns against the actual candidates. An MTA-STS wildcard matches the entire leftmost label only, not arbitrary nested names. Separately retain approved SMTP checks for STARTTLS and the receiving MTA's certificate. The HTTPS certificate validates the policy host, while the SMTP certificate validates the MX hostname used for delivery. Policy and MX validation
Monitor failure modes separately: DNS resolution, TLS certificate expiry or mismatch, HTTP errors, redirects, wrong MIME type, malformed policy and valid but incorrect policy content. Assign each class to an owner. No single serverless platform availability statement proves all of these dependencies remain healthy.
Coordinate releases with discovery and sender caches
Publish and verify the new HTTPS policy body before changing the discovery TXT id, following RFC 8461's recommended order. Record the content digest, deployment reference, previous policy and time last served. A deployment rollback that restores old bytes while leaving a new discovery state must be reviewed as a policy change, not treated as an invisible website operation. Policy updates
Distinguish HTTP cache controls from MTA-STS policy caching. Even though the policy-fetch rules disallow HTTP caching by senders, compliant senders retain a fetched policy according to max_age. A policy-host outage does not erase an existing valid cached policy; if no live policy is available, that cached policy remains applicable. A sender without a valid cached policy follows the specification's no-policy behavior when fetching fails. Policy fetching and cached state
Do not rely on endpoint deletion as emergency opt-out. Plan changes to mode and discovery with the historical cache lifetimes in view. TLS-RPT can help expose observed failures from participating senders, but it is neither real-time complete monitoring nor a replacement for direct endpoint checks. SMTP TLS reporting
Serverless-host acceptance worksheet
Use this proposed worksheet before approving a deployment or release.
- Scope: policy domain ___; hosting product/variant ___; repository owner ___; mail-policy owner ___.
- Artifact: build settings ___; output file path ___; reviewed policy bytes/digest ___; routing configuration ___.
- Host binding: issued provider target ___; custom-domain validation method ___; DNS evidence ___; certificate and renewal dependencies ___.
- Endpoint: exact URL ___; no-follow status ___; certificate result ___; content type/body ___; anonymous retrieval ___.
- Semantics: mode/max_age ___; MX patterns ___; candidate transport evidence ___; fallback/redirect rules reviewed ___.
- Release: deployment reference ___; HTTPS verification before discovery id ___; previous policy history ___; rollback owner ___.
- Operations: independent check owner ___; TLS-RPT coverage ___; alert destination ___; visual and business sign-off ___.
Fictional example: a successful HTML response
This scenario is fictional. A build change stops copying .well-known/mta-sts.txt into a static site's output. Navigation fallback returns the application's HTML page with status 200 at the policy path. A status-only monitor remains green, while the intended MTA-STS document is unavailable.
The proposed diagnosis compares the deployed artifact and retrieved body with the approved digest, restores the policy file through a reviewed release and checks the fallback exclusions. The team validates the exact custom hostname, certificate and policy before updating discovery as needed. No deployment or fetch in this story occurred. Live evidence, visual review, independent checking and accountable owner release remain pending for this draft.