MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) lets a domain publish a policy, via a DNS TXT record plus an HTTPS-hosted policy file, declaring that mail destined for it must be delivered over TLS with a valid, matching certificate — and specifying whether a connection that can’t meet that bar should be deferred or rejected. Without MTA-STS, email between two mail servers that both support TLS is usually encrypted opportunistically, but an attacker in the network path can often force a downgrade to an unencrypted connection without either side noticing. MTA-STS closes that gap by making encryption a declared, enforceable requirement — Google Workspace’s own MTA-STS documentation walks mail admins through publishing that same DNS TXT record plus HTTPS-hosted policy file for domains it hosts. Microsoft documents both directions for Exchange Online: its MTA-STS guide separates inbound protection, for domains hosted in Exchange Online, from outbound protection, the MTA-STS validations Exchange Online performs when sending mail to MTA-STS-protected domains. It’s defined in RFC 8461, whose IETF Datatracker entry shows it was published by the UTA working group as a Proposed Standard. SMTP REQUIRETLS, defined in RFC 8689, offers a similar guarantee at the level of a single message a sender chooses to protect, rather than a standing domain-wide policy.

See AdminKit’s live MTA-STS check to confirm whether a given domain actually publishes both pieces today and which mode (enforce, testing or none) its policy declares, rather than assuming from the definition above. MTA-STS is part of AdminKit’s email authentication cluster; the full AdminKit glossary lists other related terms.