Check a dependency chain rather than one TXT value
MTA-STS depends on discovery, an authenticated HTTPS policy and the receiving mail hosts described by that policy. A TXT record that looks correct can coexist with an unreachable policy file or an MX certificate that does not match. A useful checker therefore reports each stage separately and explains which later conclusions could not be reached after an earlier failure.
This guide proposes that diagnostic behavior without supplying a working EmailAuth tool. No DNS lookup, HTTPS fetch against a customer domain, SMTP connection or policy change occurred. The exact implementation gate is open: Implement and test the promised function. An article, mock-up or specification alone is not a working tool.
Derive discovery from the intended recipient policy domain
Start with the policy domain being evaluated and record why it is in scope. The discovery owner is _mta-sts followed by that domain. Under RFC 8461, discovery filters for the supported version, requires one usable matching TXT record and accepts a CNAME path to the TXT value. Multiple character strings within one TXT record are concatenated without inserted spaces; multiple matching records are a different problem.
The id field identifies a policy revision but has no implied numerical or chronological ordering. A checker should preserve the exact identifier rather than assuming a larger-looking string is newer. Absence of a usable discovery record does not automatically remove a policy that a sender has already cached. RFC 8461, section 3.1.
Authenticate the policy host and inspect the exact response
The prescribed URL uses https, the mta-sts host label and /.well-known/mta-sts.txt. For fictional recipient.example, that becomes https://mta-sts.recipient.example/.well-known/mta-sts.txt. This is a constructed illustration, not a fetched resource. The policy-host certificate must be valid for that host, unexpired and chained to a root trusted by the sender.
RFC 8461 requires an HTTP 200 response, prohibits following HTTP redirects and prohibits HTTP caching for policy retrieval. It recommends checking the text/plain media type. A checker that follows a redirect to a website homepage and then reports success has evaluated the wrong behavior. Distinguish DNS resolution, connection, certificate, status and policy-parsing failures. A certificate failure is a result to explain, not permission to bypass a security warning. RFC 8461, sections 3.2–3.3.
Bound retrieval time and response size. A server-side implementation must also control outbound destinations so a submitted name cannot cause requests to internal services or metadata endpoints. Apply network restrictions and validate the actual destination, including address changes, rather than relying only on a friendly hostname. These are proposed design requirements, not implemented defenses. OWASP SSRF prevention guidance.
Parse mode, lifetime and MX scope together
The policy declares version, mode, max_age and permitted MX patterns, with MX requirements dependent on the policy mode. Each allowed MX entry occupies its own line. A policy's max_age governs its lifetime in sender policy caches, not the DNS TTL or an HTTP cache-control header. Display these separate concepts rather than calling all three propagation time.
Compare each relevant MX candidate with the allowed patterns. RFC 8461 limits a wildcard to the entire leftmost label: *.example matches mail.example but not example or a.b.example. A broad visual substring comparison is therefore unsuitable. Retain the candidate host and the exact pattern that matched or failed. A legitimate backup MX omitted from an enforcing policy can become an availability problem. RFC 8461, sections 3.2 and 4.1.
Do not confuse the website certificate with SMTP validation
The HTTPS policy certificate authenticates policy retrieval. The receiving MX separately needs STARTTLS and a suitable certificate for its own hostname. A successful website fetch does not demonstrate the SMTP server's configuration. Any later authorized active test should retain the chosen host, connection context, certificate identity and trust result, with the tool's actual scope stated.
A checker that reads only DNS and HTTPS should report the SMTP stage as untested, not healthy. Nor does checking one candidate prove that every MX behaves the same way. Sender implementation and trust stores affect observations, so a single diagnostic vantage is not a guarantee for every correspondent. RFC 8461, section 4.
Plan a controlled move from testing to enforcement
In testing mode, an implementing sender may deliver despite policy validation failures, while compatible TLS reporting can expose those failures. In enforce mode, a sender honoring a valid policy must not deliver to a candidate that fails the required checks. Neither mode turns MTA-STS into SPF, DKIM or DMARC validation; the mechanism concerns SMTP transport.
A proposed transition should have an owner, an approved policy diff, verified primary and backup MX coverage, certificate readiness and a defined observation period. Review relevant TLS reports and actual sender behavior before deciding whether enforcement is acceptable. Absence of reports is not proof of readiness. RFC 8461, section 5 and RFC 8460.
Recovery planning must account for previously cached policies. Deleting discovery or reducing a new max_age cannot instantly shorten an already cached older policy. Retain prior policy bodies and lifetimes and plan an authorized update rather than promising immediate rollback. This guide executes no transition or recovery action.
Leave the actual trace and tool gate open
The catalogue requires: A DNS-to-HTTPS-to-MX validation trace and a controlled testing-to-enforce plan. The proposed checks above are not that trace and are not a tested checker. No environment evidence or approved transition plan has been obtained. Standards and security guidance were reviewed on 8 November 2026; independent technical review, implementation testing, live visual validation and owner publication approval remain outstanding.