Quick answer
MTA-STS (SMTP MTA Strict Transport Security, defined in RFC 8461) lets your domain tell sending mail servers that they must use authenticated TLS — STARTTLS with a valid, publicly-trusted certificate — when delivering to you, and must refuse to deliver if they cannot. You publish two things: a DNS TXT record at _mta-sts.<yourdomain> and a policy file served over HTTPS at https://mta-sts.<yourdomain>/.well-known/mta-sts.txt. The policy has three modes — testing, enforce, and none. Start in testing with TLS-RPT enabled so you can observe failures without risking delivery, then move to enforce.
What MTA-STS is for
SMTP encryption between mail servers is, by default, opportunistic: a sender tries STARTTLS, but if the handshake is stripped or the certificate is invalid, most senders silently fall back to plaintext rather than fail. That fallback is exactly what a network attacker exploits. MTA-STS removes the silent fallback for domains that opt in: it lets a receiving domain publish a policy that says "authenticated TLS is required to reach me," and compliant senders honor it.
It is a receiver-published, sender-enforced mechanism. You publish the policy for your own inbound mail; the protection takes effect when other people's servers send to you and honor what you published. It anchors trust in the Web PKI — the same certificate authorities browsers trust — so the destination must present a valid certificate that chains to a trusted root and matches an allowed MX hostname.
The DNS record and the policy file
MTA-STS uses two coordinated pieces, and you need both.
The DNS TXT record lives at _mta-sts.<yourdomain> and is short: v=STSv1; id=<unique-string>;. The id is a string that must uniquely identify the current instance of your policy. Senders cache your policy, and they detect that you changed it by seeing a new id and re-fetching. A common convention is a timestamp, for example id=20260606T120000Z.
The policy file is where the real rules live. It is served over HTTPS — with a valid certificate — at https://mta-sts.<yourdomain>/.well-known/mta-sts.txt, as key/value lines:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
max_age: 604800
The fields are: version: STSv1 (required); mode: one of enforce, testing, or none (required); mx: the allowed MX hostname patterns, one per line, with wildcards like *.example.net permitted (required unless mode is none); and max_age: the policy lifetime in seconds as a non-negative integer, up to a maximum of 31557600 (required). A sending server reads the DNS record to learn a policy exists, then fetches the policy file over authenticated HTTPS to learn what it requires.
The three modes
testing is the safe starting point. Sending servers that support TLS Reporting send you failure reports, but they still deliver the message even when MX matching or certificate validation fails. Nothing about delivery changes; you only gain visibility.
enforce is the protective mode. Sending servers MUST NOT deliver to hosts that fail MX matching, fail certificate validation, or do not support STARTTLS. This is where the downgrade and impersonation protection actually applies.
none declares that the domain has no active policy. It is the clean way to opt out — for example to retire MTA-STS — so senders stop applying a cached policy.
What MTA-STS protects against
MTA-STS defends against two specific attacks. The first is a TLS downgrade attack: an on-path attacker deletes the server's 250 STARTTLS response so the sender believes encryption is unavailable and sends in plaintext. Under an enforce policy, the sender refuses to fall back instead of leaking the message. The second is mail-server impersonation: an attacker spoofs your MX record (or otherwise intercepts the connection) to receive your mail at a host they control. Because enforce requires a valid, PKI-trusted certificate matching an allowed MX pattern, an impostor that cannot present that certificate is rejected.
What it does not do: it does not encrypt anything by itself (TLS does that), it does not authenticate the message content (that is SPF, DKIM, and DMARC), and it does not protect mail to domains that have not published a policy.
How to roll out MTA-STS safely
The safe order is policy-in-testing first, observe, then enforce — never publish enforce blind.
Begin by inventorying every hostname that legitimately receives mail for your domain; those become your mx: patterns. Publish the policy file over HTTPS with mode: testing and a sensible max_age, then add the _mta-sts TXT record with a unique id. Turn on TLS-RPT at the same time so supporting senders begin sending you aggregate reports about their TLS, MTA-STS, and DANE results against your domain.
Let reports accumulate for at least a few days. Read them for STARTTLS-negotiation failures, certificate problems, and MX mismatches, and fix the underlying issues while still in testing — a missing host in the mx: list, an expired or mismatched certificate, a relay that does not support STARTTLS. Only once the reports show legitimate senders negotiating authenticated TLS cleanly should you change mode: to enforce and bump the id so senders re-fetch the updated policy.
What this does not prove
A public check confirms whether your _mta-sts TXT record and the HTTPS policy file are present, fetchable, and well-formed, and whether your MX hosts currently present valid TLS certificates. It cannot confirm how every individual sending platform behaves, prove that no sender silently ignores your policy, or read the private TLS-negotiation outcome of a delivery that already happened — that is what TLS-RPT aggregate reports are for. Publishing a clean MTA-STS policy is necessary groundwork; the reports tell you whether it is working in practice.