The short answer is that MTA-STS uses HTTPS for policy retrieval. SMTP is the protocol that MTA-STS is designed to protect, not the one it uses to fetch its configuration.
This distinction is a fundamental part of how Mail Transfer Agent-Strict Transport Security (MTA-STS) works. The protocol's primary goal is to ensure that emails are sent over an encrypted SMTP connection, preventing them from being intercepted or tampered with in transit. To do this, it needs a secure way to tell sending mail servers about its security requirements. Using SMTP itself for this purpose would be like leaving the key under the doormat you're trying to secure.
How MTA-STS policy discovery works
Policy discovery for MTA-STS is a two-step process that involves both DNS and HTTPS. A sending mail server doesn't just assume a policy exists. It has to discover it first.
- DNS Lookup: First, the sending server checks for a specific DNS TXT record at _mta-sts.[domain.com]. The presence of this record signals that the receiving domain supports MTA-STS.
- HTTPS Retrieval: If the DNS record exists, the server then fetches the actual policy file from a well-known URL over a secure HTTPS connection. The policy is a simple text file hosted on a web server.
This policy file must be available at https.mta-sts.[domain.com]/.well-known/mta-sts.txt. The use of a "well-known" path is a standard practice that makes services and policies like this discoverable without extra configuration.
The role of HTTPS in MTA-STS security
Using HTTPS to fetch the policy is the most critical piece of the MTA-STS puzzle. It ensures the integrity and authenticity of the policy itself. If an attacker could intercept and modify the policy file, they could simply remove the security requirements, such as setting the policy mode to none. This would render the entire protocol useless by allowing a downgrade attack where the secure connection is stripped away.
The security of HTTPS, provided by TLS, guarantees that the sending mail server is talking to the correct web server for the domain and that the policy file it receives is exactly what the domain administrator intended. This prevents any man-in-the-middle attacker from altering the policy in transit.
Where does SMTP fit in?
So, if HTTPS is used for the policy, what about SMTP? The entire point of MTA-STS is to enforce security standards on the SMTP connection used to deliver email. Once a sending server has successfully and securely retrieved the MTA-STS policy via HTTPS, it then knows the rules it must follow when it connects to the recipient's mail server via SMTP.
The policy will specify that the SMTP connection must be encrypted using TLS (via the STARTTLS command) and that the certificate presented by the receiving mail server must be valid and match one of the hostnames listed in the policy. If these conditions aren't met, the sending server will refuse to deliver the email, protecting it from potential eavesdropping.
Conclusion
In summary, MTA-STS uses two protocols for two very distinct jobs. It relies on HTTPS for the secure retrieval of the security policy, ensuring the rules of engagement are authentic and untampered with. It then applies those rules to secure the SMTP connection, which is the protocol actually responsible for transporting your email. This separation of concerns is what makes MTA-STS an effective defense against sophisticated email interception attacks.
What is the file name for an MTA-STS policy?
Does MTA-STS require DNSSEC for policy discovery?
What DNS record type is used for MTA-STS policy discovery?
What port does MTA-STS typically use for policy fetching?
What is the directory path for the MTA-STS policy file?
Does MTA-STS apply to inbound or outbound mail?
