MTA-STS Validator

SMTP can use Transport Layer Security (TLS) without guaranteeing that encryption will survive an active downgrade or a broken mail-server configuration. Mail Transfer Agent Strict Transport Security (MTA-STS) gives a receiving domain a policy that supporting senders can cache and enforce on later deliveries. A valid policy tells those senders which mail exchangers are allowed and whether a failed secure connection should block delivery.

Publication has two linked parts. A DNS TXT record announces MTA-STS and carries an update identifier. A text policy served over HTTPS names the policy mode, allowed MX patterns, and cache lifetime. The HTTPS policy host needs its own valid public certificate because a sender must trust the policy before using it to judge recipient mail servers.

Policy domain

The recipient mail domain whose MTA-STS publication is being reviewed.

Policy ID

A token in the TXT record that changes when the HTTPS policy changes, prompting supporting senders to fetch the new version.

MX pattern

A permitted mail-exchanger hostname. A wildcard may replace only the complete left-most label.

Cache lifetime

The policy's max_age value in seconds. A long value improves downgrade resistance but makes a mistaken policy slower to retire from sender caches.

The three modes carry different consequences. testing lets supporting senders report failures without requiring them to withhold delivery. enforce asks them to reject insecure or mismatched delivery attempts and retry later. none removes active policy protection. Moving to enforcement before every intended MX name, certificate, and fallback path is ready can delay legitimate mail.

A publication check is not a live delivery test. It cannot show which senders support MTA-STS, what policy they have cached, whether each recipient MX currently offers STARTTLS with the right certificate, or whether TLS reports reveal failures. Those checks still matter before an enforcement decision.

How to Use This Tool:

Review one recipient domain at a time and treat the report as a point-in-time publication snapshot.

1. Enter the recipient mail domain or a URL containing it, then select Validate MTA-STS. The domain is reduced to a public hostname before DNS and HTTPS checks begin.
2. Leave Additional certificate runway at 0 for the normal seven-day check. Raise it only when your renewal policy requires more remaining certificate life; the allowed addition is 0 to 83 days.
3. Start with Validation Checks. Fix failed TXT discovery or policy-fetch checks before relying on later syntax and certificate results.
4. Compare the parsed Policy Parameters with the intended mode and every production MX hostname. A listed pattern is evidence of publication, not proof that all active MX records are covered.
5. Use Certificate Insights to confirm the observed policy-host certificate and remaining days, then rerun after DNS, policy, hosting, or certificate changes.

Interpreting Results:

Read individual failures before the percentage. A high score cannot cancel a missing TXT record, an unreachable policy, an unsupported mode, or a certificate failure. The overall label is Ready at 90% or above, Review from 70% through 89%, and Fix below 70%; those are operational review bands, not grades defined by the MTA-STS standard.

Certificate runway applies only to the HTTPS policy host observed during this run. It does not inspect certificates presented by recipient MX servers. Likewise, the MX check confirms that the policy contains patterns when an active mode needs them, but it does not compare those patterns with the domain's current MX DNS answers.

Technical Details:

MTA-STS discovery begins with a TXT record below the policy domain. The selected record must start with the case-sensitive version marker v=STSv1, and this report expects one usable record with a 1-to-32-character alphanumeric id. Policy retrieval then uses the fixed HTTPS policy host and well-known policy location.

Rule Core

The report applies 15 pass/fail checks. Some are direct RFC requirements; the one-day cache target and certificate runway are clearly separate operational readiness rules.

The HTTPS fetch validates the policy host's certificate against the platform trust store, requires TLS 1.2 or later, limits the response body to 65,536 bytes, and stops after at most four redirects. Redirects may be followed to collect evidence, but the fixed policy-address check fails whenever any redirect occurred, matching the standard's no-redirect rule.

Formula Core

Each check has equal weight. If p checks pass, the overall score is the rounded pass percentage:

Each control score uses the same formula over its own group. Certificate days remaining are the whole days between the observation time and certificate expiry, rounded down. The required runway is 7 days plus the selected addition.

What the policy means

A valid enforce policy tells a supporting sender to require both an allowed MX name and a trusted, hostname-matching certificate from the recipient server when delivering mail. testing keeps delivery non-blocking for policy failures, while none tells senders to treat the domain as having no active policy. The cache lifetime is counted from a sender's last successful policy fetch, so different senders can hold different versions during a rollout.

Privacy and Accuracy Notes:

The entered domain is sent to a public DNS resolver and to a bounded policy-fetch service, which contacts the public policy host and returns HTTPS and certificate evidence. No mailbox address, message content, or mail-server credential is needed. Resolver caches, DNS propagation, policy updates, certificate renewal, and network location can make another observer see different evidence, so rerun from other operational vantage points before a high-risk change.

Worked Examples:

References:

• RFC 8461: SMTP MTA Strict Transport Security, RFC Editor, September 2018.
• SMTP MTA Strict Transport Security registries, Internet Assigned Numbers Authority.