MTA-STS checker:
does your policy match your MX?

Type your domain above. We fetch the TXT record at _mta-sts.yourdomain, confirm exactly one v=STSv1 with an id, fetch https://mta-sts.yourdomain/.well-known/mta-sts.txt over verified TLS, parse version, mode, every mx line and max_age — then cross-check each mx pattern against your live MX records in both directions. Free, no signup.

STARTTLS is opportunistic: the sender asks "can we encrypt?", and an attacker on the path can strip the offer. The session drops to cleartext and neither side notices. MTA-STS lets your domain publish a standing instruction: TLS with a verified certificate, or don't deliver at all. It protects mail coming to you — the sending side of your reputation lives with SPF, DKIM and DMARC, which our sibling tools grade.

testing tells senders to evaluate the policy, report failures (via TLS-RPT), and deliver anyway. Nothing is blocked, exactly like DMARC's p=none, and the family resemblance is intentional. It's the correct first month of a rollout: you learn whether your own MX would fail the policy before it can hurt you. enforce is the real thing. The classic failure is retiring at testing. Once your TLS-RPT reports come back clean, the move to enforce is overdue.

Under enforce, a policy-honoring sender matches the MX host it's about to connect to against your mx patterns. No match → that host is treated as forbidden, and the mail is not delivered — it defers and eventually bounces. This is the self-inflicted-outage scenario: it happens after migrations (the MX changed, the file didn't), and it selectively hits the most careful senders — Gmail among them. Wildcard subtlety makes it worse: *.example.com covers one label only, so mail.eu.example.com slips through a wildcard that looks right.

It's a dial between protection and recoverability. Long max_age means senders keep enforcing your policy even if your DNS is briefly hijacked — that's the point. But it also means a mistake in the policy outlives the fix by the same duration. Sane practice mirrors a DMARC rollout: start at a day while testing, then raise to 604800–2419200 (1 to 4 weeks) at enforce. RFC 8461 caps it at 31557600 seconds, a year. Publish that on day one and a policy mistake keeps bouncing mail long after you fix the file.

DANE (TLSA records) is the stronger design: it binds certificates directly in DNS. But it requires DNSSEC end to end, which most domains and some large senders still don't have. MTA-STS was explicitly designed as the no-DNSSEC alternative: it borrows trust from the web PKI instead. They coexist fine; senders that support both prefer DANE. Practical answer for most domains: MTA-STS today (Gmail enforces it when sending to you), DANE when your DNS stack is ready.

Gmail has enforced MTA-STS on outbound mail since 2019. Microsoft 365 honors it outbound as well. Those two carry the bulk of the legitimate mail most domains receive, so your policy is read before delivery, not after an incident. Every policy-honoring sender can also report what it saw — publish TLS-RPT alongside, or you'll never hear it.