It's time for another installment of our DELIVTERMS series here on Spam Resource, where we help you digest and understand the alphabet soup of email technology. Today, we're looking at MTA-STS (and TLS Reporting).
MTA-STS stands for: Mail Transfer Agent-Strict Transport Security.
The concept behind MTA-STS is actually pretty straightforward. It's essentially a way for an email receiver to tell the rest of the internet: "I only speak encrypted. If you can't guarantee a secure connection, don't even bother trying to deliver the mail."
The Problem: SMTP Encryption Isn't Mandatory
To understand why we need MTA-STS, we have to look at how email encryption usually works. For a very long time,, we've relied on something called STARTTLS. When one mail server (aka MTA) connects to another, it basically asks, "Hey, do you support encryption?" If the receiving server says yes, they wrap the conversation in a secure TLS (Transport Layer Security) tunnel.
The problem? STARTTLS is opportunistic, meaning that encryption is optional, and won't be used, unless both parties in an email transaction are okay with it.
If a hacker is sitting in the middle of that connection (a man-in-the-middle attack), they can intercept the request and tell the sender that they don't support encryption, or simply strip the STARTTLS command out entirely. This is called a downgrade attack. The sending server, thinking it has no other choice, sends the email in plain text – no more encryption.
Once upon a time, optional encryption might have been good enough. Especially for us in email marketing land. Why do we care if people are able to sniff (observe) bulk email messages in transit? Is somebody going to steal that Kohl's coupon code? But, truth be told, a better secured internet is very much a good thing, and so it behooves everyone, email marketers included, to understand, and support, encryption when it comes to email.
The Solution: MTA-STS (RFC 8461)
Defined in RFC 8461, MTA-STS allows a domain owner to define and publish an SMTP encryption policy. This policy tells sending servers two very important things:
Encryption is mandatory: You must use TLS to deliver mail to me.
Verify my identity: You must check that my security certificate is valid and issued by a trusted authority.
Like with DMARC, a domain owner sets a choice of "policy" – in this case, none, testing and enforce.
To find a receiving site's policy, the sender looks up a DNS record, which points them to a secure website (HTTPS) hosted by the receiver. Because that website is protected by its own separate encryption, it's much harder for a hacker to lie to the sending server about the policy. Once a sender sees this policy, they cache it. The next time they send you mail, they already know the rules, and they won't fall for a downgrade attack.
MTA-STS is supported by Microsoft, Google, and many other mailbox providers.
The Reporting: TLS-RPT (RFC 8460)
Think of TLS Reporting (TLS-RPT) as a sidekick to MTA-STS.
While MTA-STS sets the rules, TLS-RPT (defined in RFC 8460) provides the reporting. Without that, if a sender tries to deliver mail to you but fails because the TLS connection wasn't secure enough, troubleshooting gets an awful lot harder. TLS-RPT allows the sender to send a daily report to the domain owner saying, "Hey, we successfully sent 5,000 encrypted emails, but 10 failed because (for example) your certificate expired." It is the "success and failure" ledger that helps administrators ensure their secure mail flow is actually flowing.
Why It Matters
In the old days, we were just happy if an email arrived at all. But now? Between business email compromise (BEC) and sophisticated data theft, sending email in plain text is a massive liability.
MTA-STS is essentially the "lock the front door" policy for your mail server. It moves us away from the "wild west" era of opportunistic encryption and toward a future where secure communication is the unshakeable default.
Want to learn more about deliverability terminology and other pesky acronyms related to email technology? Be sure to visit the DELIVTERMS section here on Spam Resource.
It's time for another installment of our DELIVTERMS series here on Spam Resource, where we help you digest and understand the alphabet soup of email technology. Today, we're looking at MTA-STS (and TLS Reporting).
MTA-STS stands for: Mail Transfer Agent-Strict Transport Security.
The concept behind MTA-STS is actually pretty straightforward. It's essentially a way for an email receiver to tell the rest of the internet: "I only speak encrypted. If you can't guarantee a secure connection, don't even bother trying to deliver the mail."
The Problem: SMTP Encryption Isn't Mandatory
To understand why we need MTA-STS, we have to look at how email encryption usually works. For a very long time,, we've relied on something called STARTTLS. When one mail server (aka MTA) connects to another, it basically asks, "Hey, do you support encryption?" If the receiving server says yes, they wrap the conversation in a secure TLS (Transport Layer Security) tunnel.The problem? STARTTLS is opportunistic, meaning that encryption is optional, and won't be used, unless both parties in an email transaction are okay with it.
If a hacker is sitting in the middle of that connection (a man-in-the-middle attack), they can intercept the request and tell the sender that they don't support encryption, or simply strip the STARTTLS command out entirely. This is called a downgrade attack. The sending server, thinking it has no other choice, sends the email in plain text – no more encryption.
Once upon a time, optional encryption might have been good enough. Especially for us in email marketing land. Why do we care if people are able to sniff (observe) bulk email messages in transit? Is somebody going to steal that Kohl's coupon code? But, truth be told, a better secured internet is very much a good thing, and so it behooves everyone, email marketers included, to understand, and support, encryption when it comes to email.
The Solution: MTA-STS (RFC 8461)
Defined in RFC 8461, MTA-STS allows a domain owner to define and publish an SMTP encryption policy. This policy tells sending servers two very important things:- Encryption is mandatory: You must use TLS to deliver mail to me.
- Verify my identity: You must check that my security certificate is valid and issued by a trusted authority.
Like with DMARC, a domain owner sets a choice of "policy" – in this case, none, testing and enforce.To find a receiving site's policy, the sender looks up a DNS record, which points them to a secure website (HTTPS) hosted by the receiver. Because that website is protected by its own separate encryption, it's much harder for a hacker to lie to the sending server about the policy. Once a sender sees this policy, they cache it. The next time they send you mail, they already know the rules, and they won't fall for a downgrade attack.
The Reporting: TLS-RPT (RFC 8460)
Think of TLS Reporting (TLS-RPT) as a sidekick to MTA-STS.Why It Matters
In the old days, we were just happy if an email arrived at all. But now? Between business email compromise (BEC) and sophisticated data theft, sending email in plain text is a massive liability.MTA-STS is essentially the "lock the front door" policy for your mail server. It moves us away from the "wild west" era of opportunistic encryption and toward a future where secure communication is the unshakeable default.
Want to learn more about deliverability terminology and other pesky acronyms related to email technology? Be sure to visit the DELIVTERMS section here on Spam Resource.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.