Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — MTA-STS Validator

Is encrypted delivery to your domain actually enforced?

Enter a domain and we'll check its MTA-STS record and TLS-RPT reporting over DNS, then try to fetch the policy file. You'll see whether inbound mail is required to use authenticated TLS — or quietly allowed to fall back to plaintext. Runs in your browser.

Request infrastructure review How MTA-STS works

Reads _mta-sts and _smtp._tls over DNS-over-HTTPS, then attempts the policy file. Nothing is sent or stored.

/ What this checks

MTA-STS tells other mail servers to require valid, authenticated TLS when delivering to your domain, and to refuse to fall back to unencrypted plaintext if that fails. It closes the downgrade gap left by SMTP's default opportunistic encryption, where an attacker in the middle can strip TLS and read or alter mail. This validator reads the MTA-STS DNS record and the TLS-RPT reporting record, then attempts to fetch the policy file that holds the actual rules.

The DNS records are always readable from your browser; the policy file, served over HTTPS on a different host, often can't be fetched cross-origin — that's expected and doesn't indicate a problem. What the tool reliably confirms is whether MTA-STS is configured at all and whether you've paired it with TLS-RPT reporting, which is what you need to safely move a policy from testing to enforce.

  • No fallback

    Enforce mode tells senders to require authenticated TLS and refuse plaintext fallback — closing the downgrade attack that opportunistic TLS leaves open.

  • testing → enforce

    Deploy in testing mode first, watch TLS-RPT reports until they're clean, then switch to enforce. Going straight to enforce risks blocking mail.

  • Two parts

    A DNS record at _mta-sts signals the policy exists; a file at mta-sts.domain/.well-known/ holds the rules. Both must be present and consistent.

  • TLS-RPT

    The _smtp._tls record collects daily reports of TLS failures — the visibility you need before enforcing, so you don't block legitimate senders blind.

/ How MTA-STS works

How does a domain force encrypted email delivery?

SMTP was designed to deliver mail even under poor conditions, and that resilience includes a weakness: encryption is optional. When two servers connect, they negotiate TLS if both support it, but if the negotiation fails — or is made to fail — they'll often deliver the message in plaintext rather than not at all. An attacker who can intercept the connection can exploit this by stripping the TLS offer or presenting an invalid certificate, downgrading the connection and reading or modifying mail in transit. MTA-STS exists to take that fallback option away. 

# The two DNS records this tool reads
_mta-sts.yourdomain.com    TXT   v=STSv1; id=20260620T000000
_smtp._tls.yourdomain.com  TXT   v=TLSRPTv1; rua=mailto:tls@yourdomain.com

# The policy file (HTTPS, often not browser-fetchable cross-origin)
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
  version: STSv1
  mode: enforce        # enforce | testing | none
  mx: mail.yourdomain.com
  max_age: 604800      # how long senders cache the policy

MTA-STS has two coordinated parts. The DNS record at _mta-sts carries an id that changes whenever your policy changes, signaling senders to re-fetch it. The policy file itself lives at a fixed HTTPS path on the mta-sts subdomain and contains the real rules: the mode, the list of valid MX hostnames, and a max_age that controls how long sending servers cache the policy. A sending server that supports MTA-STS reads the DNS record, fetches and caches the policy over a validated HTTPS connection, and then enforces it on every subsequent delivery to you until the cache expires.

The mode is the field that determines whether you're protected or merely observing. In testing, senders perform the TLS checks but still deliver if they fail, reporting the failure through TLS-RPT — this is how you discover problems without blocking mail. In enforce, a failed TLS check means the message isn't delivered, which is the full protection but also the mode where a mistake has consequences. Because of that, the correct deployment path is always testing first: publish the policy, collect TLS-RPT reports until they show every legitimate sender connecting cleanly, and only then promote to enforce.

This is also the honest limit of any browser-based check, including this one. The DNS records are public and always readable, so the tool can confirm MTA-STS and TLS-RPT exist and that the policy ID is present. But the policy file sits on your mta-sts subdomain over HTTPS, and browsers block most cross-origin fetches of it for security reasons — so when the tool can't read the file, that's the browser's policy, not yours. The reliable confirmation of mode and MX list comes from fetching the file server-side or from your own monitoring, which is part of what continuous infrastructure operation provides.

/ Where it fits

Should you deploy MTA-STS before or after the rest?

MTA-STS protects a different surface than SPF, DKIM, and DMARC, and the distinction tells you where it belongs in your priorities. The authentication trio answers "is this message really from the domain it claims?" — they protect against forgery and spoofing of the sender. MTA-STS answers "is the connection delivering this message to me encrypted and authenticated?" — it protects the transport, not the identity. Both matter, but they're not interchangeable, and a domain can pass all three authentication checks while still accepting downgraded plaintext connections.

In practice, the order is foundation first. Get SPF, DKIM, and DMARC to an enforced state, because they're effectively mandatory for reaching the inbox and they stop the most common attack, which is impersonation. MTA-STS comes next as transport hardening: high-value for organizations handling sensitive mail, increasingly expected of serious senders, and a meaningful defense against the specific threat of in-transit interception. It's the layer that takes you from "authenticated and trusted" to "authenticated, trusted, and encrypted end to end" — which is why the domain health scanner treats it as a bonus on top of a solid authentication foundation rather than a substitute for one.

MTA-STS is often deferred for a practical reason rather than a lack of importance: the testing-to-enforce path requires care, because a policy promoted to enforce against a misconfigured MX or certificate can block legitimate mail. That's exactly why TLS-RPT exists and why deploying the two together matters: the reports turn a risky switch into an informed one. Getting through that promotion safely, and keeping the policy correct as your MX records and certificates change, is ongoing operational work rather than a one-time publish.

/ MTA-STS FAQ

What does MTA-STS actually protect against?
MTA-STS (SMTP MTA Strict Transport Security) closes a gap in how email is encrypted in transit. By default, SMTP uses opportunistic TLS: if encryption is available, servers use it, but if it isn't, they fall back to sending in plaintext — and an attacker positioned between servers can force that downgrade or impersonate your mail server with an invalid certificate. MTA-STS lets your domain publish a policy that says 'always require valid, authenticated TLS when delivering to me, and refuse to fall back.' It turns opportunistic encryption into enforced encryption for inbound mail, defending against man-in-the-middle and downgrade attacks that opportunistic TLS alone can't stop.
What's the difference between testing and enforce mode?
MTA-STS policies have three modes. In enforce mode, sending servers that support MTA-STS will refuse to deliver if they can't establish valid authenticated TLS — full protection, but it means a misconfiguration can block mail. In testing mode, servers attempt the same checks but deliver anyway if they fail, sending you a TLS-RPT report about what went wrong — protection-aware but non-blocking, the right place to start. In none mode, the policy is effectively disabled, used when you're decommissioning MTA-STS. The standard path is to deploy in testing, watch the reports until they're clean, then switch to enforce.
Why couldn't this tool read my MTA-STS policy file?
MTA-STS has two parts: a DNS record at _mta-sts.yourdomain.com that signals the policy exists, and a policy file served over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt that contains the actual rules. A browser-based tool can always read the DNS record, but fetching the policy file from another domain is often blocked by the browser's cross-origin rules, because most policy servers don't send the headers that would permit it. That's expected and not a problem with your setup — it just means the policy file is best verified directly. The DNS record this tool confirms is the signal that MTA-STS is configured.
What is TLS-RPT and do I need it?
TLS-RPT (TLS Reporting) is the companion to MTA-STS. It's a DNS record at _smtp._tls.yourdomain.com that tells sending servers where to send daily reports about TLS connection successes and failures when delivering to you. It's how you find out that some sender couldn't establish TLS — which is exactly the information you need before switching MTA-STS from testing to enforce. You don't strictly need it, but deploying MTA-STS without TLS-RPT means enforcing encryption blind, so the two are best deployed together.
Is MTA-STS the same as DANE?
They solve the same problem — enforcing authenticated TLS for SMTP — by different means. MTA-STS uses a policy published over HTTPS, relying on the web's certificate authority system, and works without DNSSEC, which makes it easier to deploy for most domains. DANE publishes TLS certificate fingerprints in DNS and requires DNSSEC to be trustworthy. Many large providers support both; for a domain without DNSSEC, MTA-STS is usually the more practical path to enforced inbound TLS. They aren't mutually exclusive, and some domains publish both.

Encryption you can see in DNS. Enforcement you can trust in production.

Publishing MTA-STS is one thing; moving safely from testing to enforce without blocking legitimate mail is another. We deploy it with TLS-RPT, watch the reports, and promote to enforce when it's safe. Bring us your domain and we'll harden delivery end to end.

Book infrastructure review

Related capabilities