MTA-STS validator,
both ends checked.
Type a domain. We pull the DNS TXT record at _mta-sts, fetch the policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt, validate the policy syntax against RFC 8461, verify the id field is synchronised between DNS and policy, and confirm each MX declared in the policy resolves and matches the domain's actual MX records. About half of the MTA-STS deployments we audit have at least one of these out of sync — the failures are silent until enforcement fires.
Type your domain.
Strip the protocol if you have one. Subdomains work — mail.example.com is fine. We check both halves of the deployment in parallel: the DNS record (one TXT lookup) and the policy file (one HTTPS GET to mta-sts.{domain}). Most validation failures cluster on the policy file half, where misconfigurations between DNS and HTTPS are easy to miss after the initial deploy.
SMTP was never supposed to be private.
SMTP shipped in 1982 with no encryption assumption. STARTTLS (RFC 3207, 2002) added opportunistic TLS twenty years later — but opportunistic is the operative word. If a sending server can't establish TLS, it falls back to plaintext and delivers anyway. That fallback is the attack surface MTA-STS was designed to close.
The downgrade attack is mechanically simple. An attacker positioned between the sending and receiving MTAs strips the STARTTLS extension from the server's banner. The sending MTA does not know STARTTLS was offered, so it proceeds in plaintext. The attacker reads everything in clear, optionally modifies headers, optionally injects content, and forwards to the legitimate destination. From the perspective of both MTAs, delivery succeeded. From the perspective of the recipient, nothing looks wrong. This is not theoretical — Cisco Talos and Sectigo have both published case studies of large-scale stripping attacks against unprotected SMTP relays.
MTA-STS closes the fallback. A receiving domain publishes a policy declaring "TLS is required to deliver mail to me, and here are the MX hosts that should be presenting valid certificates." Sending MTAs that support MTA-STS read the policy, verify each MX has a CA-signed certificate matching its hostname, and refuse to deliver if the connection downgrades. Sending MTAs that don't support MTA-STS continue to behave as before — the policy is a one-way escalation that never breaks legacy senders. About 82% of inbound traffic to bigboxhosting.com in the past 30 days came from MTA-STS-aware senders; that number was 51% two years ago.
Industry analysts at Red Sift plus Valimail plus Proofpoint expect MTA-STS to become a hard requirement at Google and Yahoo within the next year, paralleling the trajectory SPF/DKIM/DMARC followed in 2024. The November 2025 Gmail strict enforcement was the second step on a multi-year ladder that started with SPF in February 2024 and is heading toward transport security as the next rung. Senders who deploy MTA-STS now during the optional window are buying a year of operational learning before the requirement becomes binary.
The two-piece deployment
Unlike SPF or DKIM or DMARC — which all live in DNS — MTA-STS is a hybrid: half DNS, half HTTPS. The DNS half is a TXT record at _mta-sts.{domain} announcing "I have a policy, fetch it from this URL, the version identifier is id=20260417a." The HTTPS half is a plain text file served at https://mta-sts.{domain}/.well-known/mta-sts.txt containing the actual policy: version, mode (none / testing / enforce), one or more mx: lines listing authorised MX hosts, and a max_age: in seconds.
The two halves must be in sync. The id field in DNS is what tells sending MTAs to refresh their cached copy of the policy file. Increment the id when you change the policy; sending MTAs see a new value, refetch the HTTPS file, pick up the new policy. Forget to increment, and senders cache the old policy for up to max_age seconds — typically 7 to 90 days. We have audited deployments where the DNS still pointed at id=20240101a while the policy file had been updated three times. Senders were enforcing a stale policy without knowing.
Mode progression — testing first, always
RFC 8461 defines three modes: none (effectively disabled), testing (sending MTAs try TLS validation but deliver regardless of outcome), and enforce (sending MTAs must succeed at TLS or refuse delivery). The standard rollout is at least four to six weeks in testing mode while you gather TLS-RPT data, then graduate to enforce once reports show no surprise failures.
Going straight to enforce is the most common cause of post-deployment incidents. Backup MX hosts that only activate during outages, third-party integrations that send through a different MX, archive-replay senders that haven't updated their TLS stack — any of these can produce a clean test in none and an outage in enforce. The four to six week window is not bureaucratic caution; it is the time required for traffic patterns to surface every edge case.
Why TLS-RPT is mandatory in practice
Per the standard, TLS-RPT is recommended but not strictly required. In production, treating it as optional is malpractice. Without TLS-RPT, sending MTAs that fail your MTA-STS policy reject mail silently — you have no signal that traffic stopped flowing until someone calls. With TLS-RPT, you receive daily JSON aggregate reports of TLS connection results from sending MTAs, including the specific failure type (no STARTTLS offered, certificate validation failed, hostname mismatch, etc.).
The TLS-RPT companion record lives at _smtp._tls.{domain} in DNS as a TXT record with the format v=TLSRPTv1; rua=mailto:[email protected]. Reports arrive in JSON per RFC 8460. Parsing them is a known engineering problem — every DMARC monitoring vendor that has expanded into transport security has standardised the report ingestion pipeline. Our DMARC audit includes a TLS-RPT bundling option for clients who want both feedback streams visible in one dashboard.
Four checks. The fourth is the one that bites.
The validator runs four checks per domain. Three are mechanical pass-fail. The fourth — synchronisation between the DNS id and the policy file — is what most operators get wrong because they update the policy file and forget to bump the id, which leaves receivers caching the old version until TTL expires.
The validator returns four checks per domain — the DNS record at _mta-sts.{domain}, the HTTPS-hosted policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt, the policy file syntax, and the synchronisation between the DNS id field and the policy file. Three of the four are mechanical. The fourth — synchronisation — is what most operators get wrong because they update the policy file and forget to bump the id, which means the receiver caches the old version until the TTL expires. Below: what each check means and how the failure modes typically present.
The DNS record check is binary. The record exists at _mta-sts.{domain} with a v=STSv1; id={value} format, or it does not. The id format is free-form within the spec — most operators use a date-based id like 20260109 or a sequential integer like 3. Whatever format you pick, increment it every time the policy file changes. The HTTPS policy file check is also binary in principle but more nuanced in operation. The file must be served over HTTPS with a valid certificate, must use the path /.well-known/mta-sts.txt, and must not be served from a CDN edge that can be reached by the receiver from any IP that does not present the correct certificate.
The policy file syntax check is where most failures actually surface. The file is line-based and parser-strict. Lines must use Unix line endings. The required fields are version: STSv1, mode: (one of enforce or testing or none), one or more mx: entries, and a max_age: directive between 86400 and 31557600 seconds. The validator flags syntax errors specifically. Most are line-ending issues — the policy file was edited on Windows and saved with CRLF, which some parsers reject silently and some pass with warnings.
Five findings, most of what we see.
Five findings account for the bulk of MTA-STS misconfigurations across the deployments we have audited. The pattern is consistent: the operator deployed once, did not establish a re-deployment process, and the policy drifted out of sync. Each row maps a finding to a remediation.
Five findings account for most of what the validator surfaces across the deployments we have audited. Each row maps a finding to a remediation step. Most are not deployment errors. They are operational drift — the policy was deployed correctly the first time, and the maintenance process did not get established, so the policy went stale.
| # | Finding | What to do | Time to fix | Frequency |
|---|---|---|---|---|
| 01 | id mismatch with policy file | Policy file was updated, DNS id was not bumped. Receivers cache the old version. Bump the id, propagate DNS, wait for TTL. |
5 min change + TTL wait | 38% |
| 02 | HTTPS certificate mismatch | Policy file is served from mta-sts.{domain} with a certificate that does not match the hostname or has expired. Reissue cert, configure correct SNI. |
30 min depending on cert flow | 22% |
| 03 | mx entry missing or incorrect | MX record changed (added a new receiver, retired an old one) and the MTA-STS policy did not update. Sync policy mx entries to current MX records. | 10 min change + id bump | 17% |
| 04 | Stuck in testing mode | Policy at mode: testing for >6 months. Means TLS-RPT reports were never reviewed. Read 4 weeks of TLS-RPT, fix any failures, move to enforce. |
2 weeks observation + 5 min change | 14% |
| 05 | Line-ending parser error | Policy file edited on Windows, saved with CRLF. Strict parsers reject. Re-save with Unix line endings (LF only) and bump id. | 5 minutes | 9% |
Want help deploying it?
Our Email Authentication Suite bundles MTA-STS hosting, TLS-RPT report ingestion, BIMI deployment, and DMARC monitoring in one engagement at €299/month — half the cost of buying each component separately from specialist vendors. The two-week onboarding takes you from p=none to a published MTA-STS policy in testing mode with TLS-RPT flowing into a dashboard you can actually read. Migration to enforce happens after we have four weeks of clean reports.