The short answer is no. MTA-STS does not provide authentication for the email message itself. Its purpose is to authenticate the receiving mail server and ensure the communication channel between servers is encrypted. It’s a vital piece of the email security puzzle, but it solves a different problem than sender authentication.
To understand why, we need to separate the two concepts: securing the message's journey versus authenticating the message's content and origin. MTA-STS focuses on the journey.
What does MTA-STS actually do?
MTA-STS stands for Mail Transfer Agent Strict Transport Security. Its primary job is to ensure that when one mail server sends an email to another, the connection is encrypted using Transport Layer Security (TLS). This prevents what are known as downgrade attacks, where an attacker intercepts the connection and forces it to downgrade to an unencrypted channel, allowing them to read or modify the email in transit.
Essentially, a domain owner publishes an MTA-STS policy. This policy tells sending servers that their email system will always use TLS. If a sending server sees this policy, it knows it must establish a secure, encrypted connection. The policy also includes information about the expected identity of the receiving server, which brings us to the authentication aspect.
Authentication of the server, not the email
While MTA-STS does involve authentication, it's authenticating the identity of the recipient's mail server. It works by checking that the server's TLS certificate is valid and matches the domain name specified in the MTA-STS policy. This ensures that the sending server is delivering the email to the legitimate destination and not an imposter server set up by an attacker (a man-in-the-middle attack).
This is server-level authentication. It has nothing to do with whether the email itself, the content within it, or the sender in the "From" address is legitimate. An email could be a perfectly crafted phishing attempt, but as long as it's sent over a connection secured by MTA-STS, the protocol has done its job.
How email messages are authenticated
Authenticating the email message itself is the job of other email standards, specifically SPF, DKIM, and DMARC. These technologies work together to verify that an email claiming to be from your domain was actually sent by you.
- SPF (Sender Policy Framework): This allows a domain owner to specify which IP addresses are authorized to send email on behalf of their domain. It's a list of approved senders.
- DKIM (DomainKeys Identified Mail): This adds a digital signature to the email, cryptographically linked to the domain. This signature verifies that the email content has not been tampered with since it was sent.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): This protocol ties SPF and DKIM together. It tells receiving mail servers what to do with emails that fail SPF or DKIM checks, for example, to quarantine them or reject them outright. It provides a way to enforce sender authentication.
These three work in concert to protect your domain from being used for phishing and spoofing attacks.
Encryption in transit vs. email authentication
Think of it this way: MTA-STS puts your email inside a secure, armored truck for its journey between postal hubs (mail servers). It ensures the truck is sealed and goes to the correct destination hub. DMARC, SPF, and DKIM are like the postmark and the signature on the letter inside, verifying who sent it and that it hasn't been altered.
Both are crucial. Without MTA-STS, the armored truck could be swapped for a regular van, exposing the contents. Without DMARC, the letter inside could be a forgery. For comprehensive email security, you need both: secure transport (MTA-STS) and message authentication (DMARC, SPF, DKIM).
