The short answer is no, MTA-STS (Mail Transfer Agent Strict Transport Security) does not provide sender authentication. Its purpose is different, though equally important for comprehensive email security. It's a common point of confusion because the protocol's function involves a type of authentication, but it's not authenticating the person or system that sent the email.
Instead, MTA-STS is designed to secure the connection between email servers. Its primary job is to ensure that when one mail server sends an email to another, the connection is encrypted using TLS (Transport Layer Security). This prevents eavesdropping and man-in-the-middle (MITM) attacks where an attacker could intercept, read, or alter emails in transit.
Protocols like SPF, DKIM, and DMARC handle sender authentication. MTA-STS works alongside them to protect the email after it has been authenticated and sent.
What MTA-STS actually does
The main goal of MTA-STS is to combat a specific vulnerability in the SMTP protocol: opportunistic encryption. By default, SMTP connections will try to use encryption (via a command called STARTTLS), but if an attacker interferes and pretends encryption isn't available, the connection will proceed in plain text. This is known as a downgrade attack.
MTA-STS solves this by allowing a domain to publish a policy that states its mail servers always support TLS. When a sending server that supports MTA-STS sees this policy, it knows it must establish a secure, encrypted connection. If a secure connection can't be established, the email will not be delivered.
This is where the 'authentication' part comes in, which often causes the confusion. The policy also specifies the expected names of the receiving mail servers. The sending server checks that the TLS certificate presented by the receiving server is valid and matches the names in the MTA-STS policy. This is server authentication, not sender authentication. It confirms the sending server is talking to the correct receiving server, not an imposter.
Sender authentication: SPF, DKIM, and DMARC
True sender authentication is the domain of three key protocols that work together:
- 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 answers the question: is this email coming from an approved server?
- DKIM (DomainKeys Identified Mail): This provides a digital signature that is attached to the email. The receiving server can verify this signature to ensure the email was actually sent by the owner of the domain and that the message has not been altered in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC builds on SPF and DKIM. It allows a domain owner to set a policy that tells receiving servers what to do with emails that fail SPF or DKIM checks, such as rejecting them or sending them to spam. It also provides reports on email activity.
These protocols focus on the authenticity of the email's origin, whereas MTA-STS focuses on the security of its journey.
A layered security approach
The best email security strategy uses all these protocols together. They perform distinct but complementary functions:
First, DMARC (with SPF and DKIM) authenticates that an incoming email is from a legitimate source.
Then, when sending an email, MTA-STS ensures the message is delivered to the correct server over a secure, encrypted channel, protecting its contents from being exposed or modified along the way.
In summary, MTA-STS is not a sender authentication protocol. It is a transport security protocol that authenticates the receiving mail server and enforces encryption. For authenticating who sent an email, you must rely on the established standards of SPF, DKIM, and DMARC.
