The short answer is: not quite. MTA-STS (Mail Transfer Agent Strict Transport Security) is a powerful standard designed to ensure that email is transmitted over an encrypted connection, but it has specific conditions and limitations. It doesn't guarantee that every single email will be encrypted in every possible scenario. Let's break down what it does and where its protections end.
MTA-STS is essentially a mechanism that tells other mail servers, “If you are sending me an email, you must use a secure, encrypted connection.” It’s designed to fix a long-standing vulnerability in SMTP, the protocol used to send email. By default, SMTP will try to use encryption (via a command called STARTTLS), but if an attacker interferes with the connection and removes that command, many servers will simply downgrade the connection and send the email in plaintext, completely unencrypted. This is called a downgrade attack.
MTA-STS prevents this by making that TLS encryption mandatory, not optional. If a secure connection can't be established, the email won't be delivered at all, preventing it from being sent in the clear.
How it works
For MTA-STS to work, a domain owner publishes a policy that enforces TLS for incoming mail. This is a two-step process:
- DNS Record: You create a special TXT record in your DNS. This record signals to sending mail servers that you have an MTA-STS policy they should check.
- Policy File: You then host a simple text file on a specific web address (e.g., https://mta-sts.yourdomain.com/well-known/mta-sts.txt). This file explicitly states your policy, for example, that it should be set to enforce.
When an external mail server wants to send you an email, it first sees your MTA-STS DNS record. It then fetches the policy file from the web. If that policy is in "enforce" mode, the sending server knows it is not allowed to send the email unless it can successfully create a TLS-encrypted connection.
Where MTA-STS falls short
While MTA-STS is a massive leap forward for email security, it doesn't ensure universal encryption. Here are the main limitations:
- It only protects email in transit. MTA-STS encrypts the connection between two mail servers. It does not encrypt the email message itself while it is stored on a server (at rest) or on a user's computer.
- It is not end-to-end encryption. Because the email is decrypted by the receiving mail server, server administrators (or anyone who gains access to the server) can still read the email's contents. As URIports correctly points out, it "does not protect email from someone having access to the (web)mail, workstation or mail server".
- Adoption is not universal. MTA-STS only works if the sending mail server supports the standard and checks for policies. If a sender's server doesn't support MTA-STS, it won't know to check for your policy and may send the email unencrypted (if it can't establish TLS for other reasons).
- It protects incoming mail. Implementing MTA-STS on your domain protects the mail being sent to you. It does not guarantee that the emails you send are encrypted, as that depends on whether the receiving domain has its own MTA-STS policy.
Conclusion: an essential layer of security
So, does MTA-STS ensure all mail is encrypted? No. It ensures that emails sent to your domain from a compliant mail server are delivered over an encrypted connection, which is a critical distinction.
It is a foundational security measure that closes a significant, well-known vulnerability in email delivery. When combined with its companion protocol, TLS-RPT (TLS Reporting), which sends you reports on connection failures, it provides robust protection against man-in-the-middle and downgrade attacks. While it's not the same as end-to-end encryption, it's an essential standard that every domain owner should implement for a modern, secure email setup.
