An MTA-STS deployment has two distinct formats. DNS advertises v=STSv1; id=20261107A, while HTTPS serves a line-oriented policy. Putting the DNS string in the policy file, or the policy body in DNS, does not create a working deployment.
Build the minimal policy deliberately
References: RFC 8461 §3.2.
A testing example for the reserved domain example.com is:
version: STSv1
mode: testing
mx: mx1.example.net
max_age: 86400Each field is on its own line. Serve these as plain text at https://mta-sts.example.com/.well-known/mta-sts.txt. This is an illustrative configuration, not a claim that those hosts run mail services.
Version, mode and max_age are required. At least one mx line is required except for mode none. Allowed modes are testing, enforce and none. max_age is a non-negative integer number of seconds, written with one to ten digits, with a maximum value of 31557600. One day in this example is an observation-stage choice, not a universally recommended production lifetime; longer lifetimes improve resistance to interrupted policy refresh but lengthen stale-policy exposure.
Keep parser behavior distinct from editorial lint
References: RFC 8461 §3.2.
RFC 8461 section 3.2 permits LF or CRLF line endings. Required field names and specified values are case-sensitive. Multiple MX patterns belong on separate mx lines, not a comma-separated list. Internationalized names use their ASCII A-label form.
A conforming parser ignores unknown fields and ignores subsequent copies of a non-repeated field after its first occurrence. Therefore mode: testing followed by mode: enforce does not reliably enforce anything: the first mode controls under the specification. A deployment linter should reject that ambiguity for publication even though the protocol defines how to parse it. Document this stricter editorial rule instead of claiming all duplicate fields make the protocol policy invalid.
Reproduce the critical distinctions
Create a UTF-8 file containing the four-line example. Check that splitting it into lines yields four key/value pairs and one MX value. Add a second mx line and expect two allowed hosts. Add a second mode line and compare first-value parsing with the stricter publication lint. Replace max_age with -1, 31557601 and a word, and expect each to fail the range or numeric check.
This review package includes an executable bounded fixture for the first-value, numeric-boundary and wildcard cases. It is not a complete ABNF parser or a production MTA. The newly recorded offline run passes those limited checks. Passing it proves the stated local comparisons, not DNS discovery, HTTPS certificate validation or SMTP delivery.
Publish only after the full route agrees
References: RFC 8461 §3.3, RFC 8461 §4.
Retain the exact file bytes and their hash, the discovery TXT value, the MX answers and the intended cache lifetime. Fetch the fixed URL without following redirects and inspect its body. Then verify every advertised MX's STARTTLS and certificate identity before choosing enforce. A syntactically valid file cannot compensate for a missing MX pattern or an invalid receiving certificate.
Retained historical evidence and remaining scope
The following is the retained 7 November 2026 lab record, inspected but not rerun as a network experiment for this review. New offline fixture execution is recorded separately.
The expanded isolated lab parsed actual policy-body text. A four-line enforce policy produced an enforce decision object with the allowed old MX and max_age 86400. Bodies with no MX, max_age 31557601 or STSv2 were rejected. A duplicate second mode retained the first testing value. After a real loopback STARTTLS handshake failed hostname verification, the restricted decision engine produced allow_despite_sts_failure for testing and do_not_deliver_to_candidate for enforce. These are captured fixture decisions, not observations of a production MTA queue. The parser intentionally supports only the ASCII cases listed here and is not a complete ABNF implementation.