Yes, MTA-STS not only works with STARTTLS, it is specifically designed to strengthen it. Think of MTA-STS as a security policy that enforces the use of STARTTLS, closing a critical vulnerability in how email servers traditionally handle encryption.
Without MTA-STS, STARTTLS is opportunistic, meaning encryption is optional. MTA-STS makes it mandatory, ensuring your emails are always protected in transit.
Understanding STARTTLS and its weakness
STARTTLS is a protocol command that allows an email connection to be upgraded from plain text to an encrypted connection using Transport Layer Security (TLS). When your mail server connects to another mail server to deliver an email, it looks for an indication that the receiving server supports STARTTLS. If it does, they perform a TLS handshake and encrypt the rest of the conversation.
The problem lies in the word "opportunistic." This initial conversation happens in plain text. A man-in-the-middle (MitM) attacker can intercept this connection and simply remove the STARTTLS advertisement from the server's response. The sending server, seeing no option to encrypt, will then send the email in plain text, completely exposing its contents. This is known as a downgrade attack.
How MTA-STS enforces STARTTLS
MTA-STS (Mail Transfer Agent-Strict Transport Security) solves the downgrade attack problem. It allows a domain to publish a policy that explicitly states it will receive TLS-secured connections. It effectively tells the world, "My mail servers support STARTTLS, and you must use it."
Here’s how it works in practice:
- Policy publication: You publish a DNS TXT record for your domain that indicates you support MTA-STS. This record points to a policy file hosted on a secure web server.
- Policy fetching: When another mail server wants to send you an email, it first checks for your MTA-STS DNS record. It then fetches the policy file.
- Enforcement: Your policy file specifies the mode (e.g., enforce), your mail server hostnames (MX records), and a maximum validity period. The sending server caches this policy.
- Secure connection: For the duration of the policy's validity, the sending server will only send email to your domain if it can successfully establish a TLS-encrypted connection (using STARTTLS) with a valid certificate. If it can't, it will not deliver the email, preventing it from being sent insecurely.
By enforcing strong encryption, MTA-STS helps prevent attackers from downgrading the connection to an unencrypted one. This makes the entire process far more secure.
What about TLS-RPT?
TLS-RPT (TLS Reporting) is a companion protocol that works alongside MTA-STS. It allows you to specify an email address in a DNS record where sending servers can send reports about any TLS connection failures they experience when trying to email you. These reports are crucial for diagnosing and fixing issues with your MTA-STS implementation, such as certificate problems or misconfigurations, without disrupting your mail flow.
Conclusion
So, to directly answer the question: MTA-STS does not replace STARTTLS. Instead, it acts as a mandatory security layer on top of it. STARTTLS provides the mechanism for encryption, and MTA-STS provides the policy that ensures this mechanism is always used. Implementing both is a significant step towards securing your domain's email against in-transit attacks.
