MTA-STS Validator

MTA-STS is a receiving-domain policy for safer SMTP delivery. Ordinary SMTP can negotiate TLS, but a sender that has no stored policy may still fall back to weaker delivery when DNS, routing, or TLS negotiation is interfered with. Mail Transfer Agent Strict Transport Security gives a domain a published rule that supporting senders can cache before accepting fallback risk.

The policy is split across DNS and HTTPS on purpose. DNS advertises that the domain has an MTA-STS policy and includes an update identifier. The HTTPS policy describes the allowed mail exchanger names, the policy mode, and the cache lifetime. A sender that supports MTA-STS checks both publication points, remembers the result for the declared time, and applies the cached rule on later delivery attempts.

TXT record

The discovery record under the mail domain. It must identify the MTA-STS version and include an id token that changes when the policy changes.

Policy host

The HTTPS host that serves the policy text and presents the certificate checked during policy retrieval.

Policy mode

none disables policy use, testing publishes a non-blocking policy, and enforce asks supporting senders to refuse delivery when the policy cannot be met.

MX pattern

A permitted mail exchanger name or wildcard pattern. Active policies need at least one pattern so senders know which delivery hosts are acceptable.

Mode choice is the main rollout decision. testing is useful while a domain is proving that DNS discovery, policy hosting, MX coverage, and reporting are stable. enforce gives the control real effect, but it also raises the cost of mistakes. A bad certificate on the policy host, a stale TXT id, or a missing MX pattern can make mail delivery fail for senders that honor the policy.

MTA-STS validation is publication evidence, not a complete mail-security audit. It can show that the public record, policy text, cache window, MX patterns, and policy-host certificate line up at lookup time. It cannot prove that every sender supports MTA-STS, that every cached sender has refreshed its policy, or that every MX server negotiates SMTP TLS correctly under real traffic.

How to Use This Tool:

Use the validator before first publication, before changing from testing to enforce mode, after MX changes, and after certificate or hosting changes on the MTA-STS policy host.

1. Enter the recipient mail domain in Domain. A value such as example.com works best; URL-style input is reduced to the hostname when possible.
2. Press Validate MTA-STS. If Domain is required. appears, remove mailbox prefixes, spaces, or unsupported characters and run the lookup again.
3. Start with MTA-STS Summary. The summary shows the score, status band, selected TXT record, policy mode, readable max_age, TXT TTL, fetch time, and certificate status.
4. Open TXT Record Details to check the discovery host, TXT answers, selected v=STSv1 record, id token, lookup time, TTL, and record count.
5. Open Policy Parameters to review the fetched policy, HTTP status, content type, redirect hops, policy version, mode, max_age, MX patterns, and raw policy text.
6. Use Validation Checks when the score is below 100%. Failed rows name the area to repair, such as a missing id, wrong content type, weak cache window, absent MX pattern, or certificate issue.
7. Use Certificate Insights, Control Readiness, and MTA-STS Control Profile for handoff evidence, then rerun the same domain after each DNS, policy, MX, or certificate change.

Interpreting Results:

The percentage score is a validator score, not a value defined by the MTA-STS standard. A 100% result means all visible publication checks passed during this lookup: TXT discovery, HTTPS policy retrieval, directive syntax, cache-window bounds, active-mode MX coverage, and policy-host certificate freshness.

• Ready starts at 90%. Treat it as a strong publication check, not proof of universal sender support or live SMTP delivery.
• Review covers 70% to 89%. One or more discovery, policy, cache, MX, or certificate items needs attention before an enforcement decision.
• Fix covers scores below 70%. Repair failed rows and rerun before calling the domain MTA-STS ready.
• Policy mode matters as much as syntax. testing may pass many checks, but it does not request delivery blocking.
• Redirect hops deserve manual review. The report can record a final successful fetch, but sender behavior should not depend on redirect handling.
• Certificate freshness is stricter than basic validity. A certificate can still be valid now while failing the seven-day freshness check.

When the TXT lookup fails, repair DNS discovery first. When policy retrieval fails with a host, timeout, content, size, redirect, or certificate message, fix the HTTPS policy host before relying on policy fields or the control profile.

Technical Details:

MTA-STS uses a two-part publication model. The TXT record announces the policy version and update identifier. The HTTPS policy file carries line-based directives that describe the active behavior. Senders that implement the standard can cache that policy for the declared lifetime and compare later MX delivery attempts with the cached MX patterns.

The policy mode changes how the same syntax affects delivery. none is a publication off switch. testing allows monitoring and rollout without mandatory blocking. enforce asks supporting senders to fail delivery when the published policy cannot be satisfied. That makes cache lifetime, certificate renewal, and MX pattern accuracy operationally important.

Rule Core

Formula Core

The overall score is the rounded percentage of the 15 validation checks that pass. If p is the number of passing checks and n is 15, the score is:

For example, 13 passing checks produce round(100 * 13 / 15) = 87%, which lands in the Review band. Control readiness rows use smaller local check sets for TXT discovery, policy fetch, policy syntax, cache window, and policy certificate, so a control score can differ from the overall percentage.

The policy retrieval evidence includes HTTP status, content type, redirect count, response size, fetch time, final policy location, and certificate metadata for the policy host. SMTP TLS negotiation, MX server certificate checks, DNSSEC validation, DANE, SPF, DKIM, DMARC, and TLS report history are separate controls and are not included in the MTA-STS score.

Privacy and Accuracy Notes:

This validator performs live network checks. The entered domain is used for public DNS TXT lookup and for a server-assisted HTTPS retrieval of the MTA-STS policy so certificate details can be inspected. The policy host can see that its policy was requested, and the generated report may display public TXT answers, policy text, certificate metadata, readiness rows, and handoff links.

• No mailbox content is needed; the input is a domain name.
• DNS answers, policy responses, and certificates can change after lookup because of TTLs, cache state, renewals, and provider changes.
• The score checks publication evidence, not historical sender behavior, actual message delivery, or TLS report data.

Worked Examples:

Enforce-ready publication

A domain publishes v=STSv1; id=20260531, serves a policy with version: STSv1, mode: enforce, max_age: 2592000, and two mx directives, and has a policy-host certificate with 40 days remaining. MTA-STS Summary can show 100%, Policy Parameters shows a 30-day cache window, and Certificate Insights shows a healthy Days remaining value.

Valid policy with a weak cache window

A policy using mode: testing and max_age: 3600 can still be reachable and parse correctly. Validation Checks fails the max_age >= 86400 seconds row, and Control Readiness lowers the cache-window score. Raise the cache lifetime, update the TXT id if the policy changed, and rerun the domain.

TXT discovery passes but policy retrieval fails

A domain may return a primary TXT record while the policy fetch reports MTA-STS host was not found in DNS. or TLS certificate validation failed while fetching policy. That points to the HTTPS policy host, not the TXT record itself. Repair host DNS or the certificate, then confirm Policy Parameters and Certificate Insights populate cleanly.

Redirect evidence needs review

If Policy Parameters shows a nonzero Redirect hops value while the final HTTP status is 200, the validator still has enough evidence to parse the final policy. Treat the redirect as a standards review item before enforcement because sender behavior should not depend on redirect following.

FAQ:

Glossary:

MTA-STS

Mail Transfer Agent Strict Transport Security, a policy mechanism for SMTP transport security.

Policy domain

The recipient mail domain whose MTA-STS TXT record and HTTPS policy are being checked.

Policy host

The HTTPS host under mta-sts.<domain> that serves the MTA-STS policy file.

MX directive

A policy line that names a permitted mail exchanger pattern for active MTA-STS modes.

max_age

The policy cache lifetime in seconds.

id token

The TXT record identifier that signals a policy update to senders with cached policy data.