MTA-STS Validator

Introduction:

Mail Transfer Agent Strict Transport Security, usually shortened to MTA-STS, lets a receiving mail domain publish how other mail servers should reach it over authenticated Transport Layer Security (TLS). That matters because SMTP delivery has long allowed fallback behavior, so a wrong MX host, a stale policy, or a broken certificate can weaken transport security without producing an obvious dashboard alarm. This validator checks the public MTA-STS record, the published policy file, and the certificate that serves that policy.

That makes the report useful right after DNS edits, mail hosting migrations, policy rollouts, and certificate renewals. Instead of reading raw TXT answers and a plain-text policy file by hand, you get a compact review of whether the published pieces line up closely enough for another mail system to discover, cache, and trust them.

A common use case is the move from a monitoring posture to an enforcing posture. A team may publish a new policy, raise the cache lifetime to several days or weeks, and expect senders to use only the listed MX hosts. The report quickly shows whether the discovery record, policy text, and policy-host certificate support that plan before anyone assumes the rollout is complete.

The tool is also practical when something looks partly right. A domain can have a valid TXT record but still fail because the policy host does not answer cleanly over HTTPS, the certificate is near expiry, or the cached policy identifier was never changed after an update. Separating those layers is often what turns a vague mail-security concern into a short repair list.

A high score still has a narrow meaning. It says the visible TXT record, policy file, and policy-host certificate satisfied this tool's checks at fetch time; it does not mean every sender supports MTA-STS, that every sender has refreshed its cached policy, or that live SMTP delivery to each MX target has been tested end to end.

Everyday Use & Decision Guide:

Start with the exact recipient domain, not a mailbox address, URL, or mail host name, and run Validate MTA-STS after any change to DNS, policy text, or certificates. The MTA-STS Summary is best used as triage. If Mode, max_age, and the certificate badge all look healthy, move into the detail tabs to confirm why.

• TXT Record Details is the first trust check. Confirm the host is _mta-sts.<domain>, the primary record starts with v=STSv1, and the ID token changed when you expected a policy refresh.
• Policy Parameters should show a reachable policy URL, a valid mode, a sensible max_age, and the MX patterns you intended to publish. If redirects or fetch time look odd, fix that before focusing on the percentage.
• Validation Checks tells you which rule failed. A miss on max_age >= 86400 seconds or Policy lists MX hosts is usually easier to act on than a raw score drop.
• Certificate Insights matters whenever the fetch works but the certificate badge is weak. A policy host that expires soon can pass now and fail for other senders before the next review.

The most common misread is to treat a passing TXT record as proof that MTA-STS is ready. It is only the discovery step. Before you trust the result, compare Policy mode, MX hosts, and Not after, then keep the Evidence Bundle JSON if another team needs to review the same state after a fix.

Technical Details:

The validator follows the same broad path a sending system would use to discover policy. It sanitizes the supplied domain, queries the dedicated _mta-sts TXT host, joins quoted TXT fragments, and parses the resulting semicolon-delimited key-value pairs. On the policy side it fetches https://mta-sts.<domain>/.well-known/mta-sts.txt, parses key: value lines, ignores comments, and collects every mx directive so the published host patterns can be reviewed together.

The policy fetch is done through the tool's helper endpoint because a browser page cannot directly inspect the remote TLS certificate in a useful way. That helper follows up to four redirects, enforces HTTPS with certificate validation, requires TLS 1.2 or newer, caps the downloaded policy at 65,536 bytes, and returns the certificate subject, issuer, subject alternative names, fingerprints, and validity window for the final policy host.

Results are then reduced to twelve boolean checks and a rounded percentage score. The score is a convenience summary, not a protocol field. Its value comes from making discovery issues, policy-shape issues, cache-window issues, and certificate issues visible in one place without hiding which specific rule failed.

Rule Core:

The score is the fraction of passed checks multiplied by 100 and rounded to a whole percent.

Limits and Failure Behavior:

The tool accepts only hostname-style domains and strips URL prefixes or trailing dots before lookup. If DNS lookup fails, the report can still show a policy-host error separately when that fetch proceeds. When the policy fetch fails, the helper maps common problems into concrete messages such as host not found, too many redirects, timeout, oversized policy response, host unreachable, or TLS certificate validation failure. That distinction is useful because TXT discovery and policy hosting often break for different reasons.

Step-by-Step Guide:

Use the report as a short publication check, then read the failed rule before changing anything.

1. Enter the target domain in Domain and select Validate MTA-STS. If the alert says Domain is required., correct the input before trying again.
2. Read MTA-STS Summary first. A missing score or a red error banner means you need to resolve discovery or fetch problems before comparing details.
3. Open TXT Record Details and confirm the host, primary record, Version, and ID. If TXT lookup failed. appears, fix DNS publication for _mta-sts.<domain>.
4. Open Policy Parameters and inspect Policy URL, HTTP status, Policy mode, max_age, and MX hosts. If the error mentions redirects, timeout, or TLS validation, repair the policy host before treating the policy as live.
5. Open Validation Checks and Certificate Insights. The failed row tells you which rule blocked the score, while Not after and Days remaining show whether a certificate renewal is becoming urgent.
6. Use JSON or Evidence Bundle JSON when the review needs to be shared, archived, or repeated after a change. Then run the same domain again so the new fetch reflects the published state.

A clean rerun after each DNS, policy, or certificate change is the quickest way to confirm that the published state now matches intent.

Interpreting Results:

The score is a compact review signal, not a substitute for judgment. A value of 100% means all twelve checks passed for the domain state fetched at that moment. Lower scores usually become actionable once you read which row failed in Validation Checks and whether the weak point is discovery, policy shape, cache lifetime, or certificate state.

• A failure on max_age >= 86400 seconds means the published cache lifetime is shorter than this validator's recommended floor, even if the rest of the policy is coherent.
• A passing Policy certificate valid check says the policy host can be trusted now. The separate freshness check is stricter and warns when fewer than seven days remain, but neither row tests the SMTP certificates presented by the MX hosts themselves.
• A high score does not mean all senders already enforce the policy. Verify Policy mode, MX hosts, and Not after, then confirm live mail flow separately if the rollout is security-sensitive.

Worked Examples:

A ready policy before enforcement

A domain publishes mode: enforce, max_age: 2592000, and two MX patterns, while the policy-host certificate has 43 days left. In that case MTA-STS Summary can reach 100%, Policy Parameters will show a 30-day cache window, and Certificate Insights will show a healthy Days remaining value. That is the profile you want before treating an enforcement rollout as complete.

A policy that is valid but too short-lived

Suppose everything is present except the policy uses max_age: 3600. The fetch can still work, Policy mode may still be valid, and most checks can pass, but Validation Checks will fail on max_age >= 86400 seconds. A result like that means the policy shape is close, yet the cache window is too short for the validator's pass criteria and should be increased before you rely on it operationally.

A TXT record that points to a broken policy host

A domain can publish a correct TXT record and still return TLS certificate validation failed while fetching policy. or MTA-STS host was not found in DNS. The score then drops sharply because the policy and certificate checks fail together, even though the TXT section looks healthy. The corrective path is to repair the mta-sts host, present a certificate valid for that host name, and rerun the same domain until both Policy Parameters and Certificate Insights populate cleanly.

FAQ:

Glossary:

References:

• Margolis, Brotman, Jones, and Risher. SMTP MTA Strict Transport Security (MTA-STS), RFC 8461, IETF, September 2018. https://www.rfc-editor.org/rfc/rfc8461