Dr.Who

mta-sts checker

fetch and validate a domain's MTA-STS policy (RFC 8461) — mode, MX list, max_age. tells you whether inbound SMTP is TLS-enforced. part of the drwho.me domain dossier.

mta-sts

info
Open standalone →

checking mta-sts…

Overview

MTA-STS (mail transfer agent strict transport security, RFC 8461) solves a long-standing SMTP weakness: starttls has always been opportunistic — a man-in-the-middle can strip the STARTTLS advertisement and force plaintext delivery with no warning. MTA-STS fixes this by publishing, over HTTPS, a signed policy that authorised senders can cache and enforce. the policy is discovered in two steps: first, a TXT record at `_mta-sts.<domain>` must carry a `v=STSv1; id=<token>` pair that signals a policy exists and provides a version id for caching. second, the policy file itself is fetched from `https://mta-sts.<domain>/.well-known/mta-sts.txt` — note the HTTPS requirement, which is where the trust comes from. the file declares `mode:` (enforce, testing, or none), a list of `mx:` patterns that match the domain's authorised inbound servers, and `max_age:` in seconds. sending MTAs cache the policy for up to max_age and, in `enforce` mode, refuse to deliver if starttls is unavailable or the server certificate doesn't match the declared mx patterns. this tool checks the TXT record, then fetches and parses the policy file, surfacing all three mode/mx/max_age fields.

How to use

  1. enter a bare domain — public fqdn only. no scheme, no port.
  2. check the TXT record — the tool queries `_mta-sts.<domain>` for a TXT record starting with `v=STSv1`. the `id=` value is a version token — senders re-fetch the policy when the id changes.
  3. read the policy file — policy is fetched from `https://mta-sts.<domain>/.well-known/mta-sts.txt`. mode `enforce` is the goal; `testing` means monitor-only (delivery proceeds regardless of failures); `none` actively revokes a previously published policy.

Examples

example 1 — google publishes enforce-mode MTA-STS on gmail.com — a good reference implementation.
input
gmail.com
output
v=STSv1; id=…, mode: enforce, mx: [*.gmail.com, …], max_age: 86400
example 2 — most domains don't publish MTA-STS yet. absence is not an error, just a finding.
input
domain with no MTA-STS
output
no TXT record at _mta-sts.<domain> — check returns not_applicable

Common mistakes

  • the policy file MUST be served over HTTPS — MTA-STS's trust model depends on the policy URL being `https://mta-sts.<domain>/...` with a valid certificate. if the subdomain's TLS cert is expired, self-signed, or missing, senders cannot retrieve the policy and will fall back to opportunistic TLS. the MTA-STS check and the tls-certificate-checker on `mta-sts.<domain>` are complementary.
  • `mode: none` actively revokes your policy — if you previously published `enforce` or `testing` and then switch to `mode: none`, senders that cached your old policy will continue enforcing it until max_age expires. to revoke cleanly: change to `mode: none`, bump the TXT `id=` token, and wait for max_age to expire across all senders' caches.
  • mx patterns in the policy must match your actual MX records — senders enforce the mx pattern list against the target MX hostname at delivery time. if you add a new mail provider but forget to update the MTA-STS policy's `mx:` list, the new provider's servers will be rejected in enforce mode. keep the policy and your MX records in sync.
  • version id changes trigger a re-fetch — senders cache the policy for max_age seconds. to force an early re-fetch (e.g. after you've changed the mode or mx list), you must change the `id=` value in the TXT record. bumping a timestamp works fine: `id=20260101000000`.

FAQ

how is MTA-STS different from DMARC?

DMARC (RFC 7489) authenticates the sender's From: address and governs what receivers do with fraudulent mail. MTA-STS governs how senders transport mail to your server — it enforces TLS at the SMTP layer. they solve different problems and complement each other.

does MTA-STS protect against all SMTP downgrade attacks?

in enforce mode, yes — senders will not deliver if STARTTLS is unavailable or if the server certificate doesn't match the declared MX. it does not protect if the attacker can forge a valid certificate for the MX hostname (that's a CA problem) or if the attacker can manipulate the HTTPS fetch of the policy itself.

what's the recommended max_age?

RFC 8461 recommends starting with a short value (e.g. 86400 = 1 day) while in testing mode, then increasing to 604800 (1 week) or 31557600 (1 year) in enforce mode. a longer max_age means faster enforcement but a larger blast radius if you need to revoke urgently.

do all sending MTAs support MTA-STS?

major providers (google, microsoft, protonmail) support it. smaller MTAs and legacy mail servers may not, meaning they'll fall back to opportunistic TLS regardless of your policy. MTA-STS is additive — senders that don't support it are unaffected.

can ai agents call this?

yes — dossier_mta_sts on the mcp endpoint at drwho.me/mcp/mcp.

Related tools

  • tls-rpt checker — look up a domain's TLS-RPT (SMTP TLS Reporting) policy.
  • mx lookup — list the mail exchangers (MX records) a domain advertises, sorted by priority.
  • tls certificate checker — inspect a domain's TLS certificate: subject, issuer, validity, SANs, fingerprint.

References

  1. RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)
  2. RFC 5321 — Simple Mail Transfer Protocol
ad slot · tool-mta-sts-checker