The short answer is no, MTA-STS (Mail Transfer Agent Strict Transport Security) does not secure the entire email path. While it’s a critical security standard that addresses a major vulnerability in email delivery, its protection is specifically focused on one particular segment of an email's journey: the connection between SMTP servers.
To understand its limitations, we first need to understand what it does. Essentially, MTA-STS is designed to ensure that when one mail server sends an email to another, that connection is encrypted using TLS (Transport Layer Security). This prevents opportunistic eavesdropping and man-in-the-middle (MITM) attacks where an attacker could intercept or alter emails in transit between servers.
Where MTA-STS provides protection
Email has a built-in command called STARTTLS, which attempts to upgrade an insecure connection to a secure, encrypted one. The problem is that this process is optional and vulnerable. An attacker can perform a "downgrade attack" by simply intercepting the STARTTLS command, forcing the email to be sent in plaintext without the sender or receiver knowing.
MTA-STS solves this. By publishing an MTA-STS policy, a domain owner can tell sending servers that their mail servers expect a secure TLS connection. If a secure connection cannot be established, the email will not be delivered. This effectively makes TLS encryption mandatory for any server that supports the standard, closing the loophole that allows for downgrade attacks.
The gaps in MTA-STS coverage
The email path is more than just a single jump between two servers. An email travels from the sender's client (like Outlook), to their sending mail server, potentially through several intermediate servers, to the final receiving mail server, and then to the recipient's client (like the Gmail app). MTA-STS only protects one of those hops, specifically the final one between the last sending server and the recipient's mail server.
Here are the key areas MTA-STS does not cover:
- End-to-end encryption: MTA-STS encrypts the transport channel, not the email message itself. The email still exists in an unencrypted state on the sending and receiving servers. Anyone with access to those servers can read the message.
- Email at rest: Once the email arrives and is stored on the recipient's mail server, MTA-STS's job is done. It does not protect the data while it is sitting on a hard drive.
- Internal hops: It doesn't secure the connection between the sender and their own mail server, nor any intermediate hops an email might take before it reaches the final mail server.
- The final mile: The connection between the recipient's mail server and their email client (e.g., phone or computer) is not covered by MTA-STS. This link is typically secured by other protocols like HTTPS, IMAPS, or POPS, but it's a separate security consideration.
A piece of the security puzzle
It's important to view MTA-STS not as a silver bullet, but as a vital layer in a comprehensive email security strategy. It is designed to work alongside other crucial protocols. As Mark Loveless points out, it complements DMARC; while DMARC authenticates the sender to protect against spoofing, MTA-STS protects the data in transit for inbound mail.
In conclusion, MTA-STS significantly hardens email security by mandating encryption for server-to-server communication, preventing a whole class of dangerous eavesdropping and modification attacks. While it doesn't secure the entire email path from end to end, it secures one of the weakest links in the chain, making it an essential standard for any organization that takes email security seriously.
