Define adoption and availability as separate measures
MTA-STS adoption can refer to DNS discovery, retrieval of a syntactically valid policy, publication of an enforcement mode or observed compatibility with the domain's receiving MX route. Policy-host availability is another property: it concerns whether the HTTPS endpoint was reachable and valid at the observation time. A study should define these measures separately instead of treating one successful fetch as complete transport-security adoption.
RFC 8461 defines MTA-STS discovery, policy retrieval, validation and caching. It supports a reproducible measurement design, not an assertion that a dataset exists. This article contains no domain scans, availability percentages, connection tests or longitudinal findings. All examples are explicitly hypothetical.
Establish the receiving-domain population
MTA-STS concerns the receiving domain's mail route. A list of websites, outbound sender brands or customer organizations is not automatically an appropriate list of receiving domains. Define the unit, selection method and exclusions before collection. Record whether the sample includes domains without a usable mail route and how those cases affect each metric rather than silently dropping them.
Freeze the input list and preserve its source, date, normalization rules and hash. If the list changes between runs, retain membership history. A domain entering or leaving the sample can alter apparent adoption without any change to its policy. Do not call a convenience sample a global estimate unless the sampling design supports that inference. This manuscript provides no such estimate.
Separate DNS discovery from HTTPS retrieval
RFC 8461 defines the discovery record at the _mta-sts owner and the policy retrieval location under the mta-sts host at the well-known path. The discovery identifier signals policy changes; it is not a certificate fingerprint or proof that the endpoint currently works. Record the DNS answer, owner, resolver and time independently of the subsequent HTTPS observation.
The standard requires HTTP 200 OK for policy retrieval and says senders must not follow HTTP redirects in that retrieval procedure. It also says senders must not use HTTP caching for policy retrieval, distinct from MTA-STS policy caching. The method should preserve response status and redirect behavior rather than accepting any successful-looking browser destination. No endpoint was fetched or redirect followed during this work.
Validate the policy and connection under the stated rules
The policy contains version, mode, MX patterns and maximum age under RFC 8461's syntax. Retain the actual bytes and parser version. A policy using testing mode is not the same measured category as enforce mode. A none policy is another state that should be named rather than collapsed into a generic adoption count. Report content-type handling with the standard's requirement strength: senders should validate text/plain, rather than inventing a universal stronger requirement.
HTTPS certificate validation is a separate observation. Record the requested hostname, endpoint, time and actual validation result. A network failure, certificate failure, unexpected status and malformed policy have different meanings and should remain separate in the error log. Do not infer that a policy is absent merely because one observation location could not reach it, and do not ignore connection errors to produce a larger adoption numerator.
Compare policy patterns with the intended MX route
A syntactically valid policy can still describe the wrong receiving hosts. RFC 8461 defines matching of exact MX hostnames and wildcard patterns. A wildcard is not an unrestricted glob anywhere in a name; the method must implement the standard's defined syntax and matching. Retain the MX observations and the matching decision for each host within the measured scope.
An HTTPS fetch alone does not establish that every MX endpoint offers a valid TLS service matching the policy. If the study does not perform authorized SMTP observations, state that route compatibility is unmeasured. If later testing is approved, keep its connection evidence and population separate from policy-host availability. Do not claim end-to-end enforcement from DNS and HTTP alone.
Account for cached policy behavior
Senders can retain an MTA-STS policy for its maximum age under the protocol. A temporary policy-host outage can therefore affect a sender with a usable cached policy differently from a sender discovering the domain for the first time. An external measurement probe generally does not know every sender's cache state. The study must not translate endpoint downtime directly into a universal period of unprotected mail.
Similarly, the discovery identifier and observed policy version need a temporal record. If a policy changes during collection, preserve the sequence rather than joining the old DNS observation to a new body without explanation. Repeated measurements should record probe state and any intentional cache treatment. The method must distinguish its measurement behavior from a full sending MTA implementation.
Design the availability schedule before collection
Define probe locations, cadence, timeout, retry policy and classification rules in advance. An endpoint that fails once and succeeds on retry should not disappear from the error record. Report attempted observations, successful observations and failure categories using a clear denominator. If maintenance windows or unreachable vantage points are excluded, retain the reasons and show how exclusions change the result.
No cadence or service-level target is imposed universally by this article. Choose a schedule suited to the research question and authorization, avoiding excessive load. Document the tooling version and dependencies so another analyst can reproduce the method. Actual availability conclusions require collected data; a proposed schedule is not evidence that a service met or missed any target.
A versioned dataset worksheet
Create fields for sample version, receiving domain, observation time, DNS discovery result, policy identifier, HTTPS endpoint, status, certificate result, content type, body hash, parsed mode, MX patterns and maximum age. Add MX observation references, matching results, error category, retry history and exclusion reason. Preserve raw evidence separately from normalized classifications.
RFC 8460 defines SMTP TLS reporting, which can provide another perspective when legitimately available. Such reports are not equivalent to an external availability probe and do not automatically cover every sender. If included, document their source and scope separately. This draft collected neither probes nor reports and does not imply exact correlation between them.
Fictional diagnosis: endpoint outage becomes an enforcement claim
A fictional study observes one failed HTTPS retrieval and labels the receiving domain as having no MTA-STS protection for the whole day. The proposed review identifies missing evidence: the observation covered one time and vantage point, and senders may have cached policies. The correct conclusion is narrower, describing the failed retrieval and its error category within the measured schedule.
The team would retain subsequent observations and report the denominator rather than erase the failure or extrapolate it into universal mail behavior. This is a fictional methodological example, not an observed outage or a claim about a named domain. No network probe or email delivery test was executed.
Release only reproducible findings
The catalogue requires a versioned dataset, query method and error/exclusion log that another analyst can reproduce. Those original artifacts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a study design and fictional diagnosis, not adoption counts, availability results or an end-to-end transport-security assessment.