I’m not going to beat around the bush, this blog is going to be technical. So, if you’re reading this late at night, it might be that the main thing you’ll get out of this article is a good night’s sleep.
MTA-STS is an acronym that not many have come across - and for good reason! In this internet age, memes travel fast, and security standards travel slow. MTA-STS has only been around since 2018 (RFC 8461) which means it’s basically a toddler in the eyes of the world. Just look at DMARC, it’s over 10 years old but only now is there any buzz about it.
MTA-STS explained in brief
Short for Message Transfer Agent Strict Transport Security, MTA-STS has been designed to ensure that email communications are conducted via the encrypted tunnel.
“Isn’t that what TLS is for?” Well yes, but also, no.
Transport Layer Security
TLS (Transport Layer Security) is the cryptographic protocol which essentially provides security over the communication channels for the internet. In other words, email messages themselves aren’t encrypted, but the transport method is.
One well known example of TLS is when you see https://, the communication with that website is secured by TLS. TLS-RPT can provide reports on whether these communications have been done successfully.
SMTP, TLS and MTA-STS
Where MTA-STS comes in is in direct relation to email communications – more specifically Simple Mail Transfer Protocol (SMTP). SMTP historically lacked robust security measures and whilst TLS was introduced to encrypt SMPT communications, it remained optional and vulnerable to DNS tampering.
MTA-STS ensures that TLS is always used and provides a mechanism for sending servers to refuse delivery to servers lacking TLS support or trusted certificates. MTA-STS also aims to bolster email security as it was developed in collaboration with M3AAWG (Messaging, Malware, and Mobile Anti-Abuse Working Group).
Configuration modes for MTA-STS
There are 2 main configuration modes for MTA-STS – testing and enforced. Here’s what you need to know:- Testing mode: When MTA-STS is in testing mode, it validates connections but there is no enforcement. Email delivery occurs even if the recipient domain doesn’t support MTA-STS. The purpose of Testing mode is to monitor and identify issues, similar to DMARC’s p=none configuration.
- Enforce mode: In enforce mode, MTA-STS strictly adheres to TLS requirements. If a recipient domain supports MTA-STS and the sender doesn’t, email delivery is refused. It ensures robust security but requires careful configuration and testing before enabling.
There are further configuration requirements for MTA-STS including setting a “max-age” for the lifetime of the policy (defined in seconds) to determine how long servers should cache MTA-STS policies. This needs to be updated over time and can be time consuming, similar to renewing SSL certificates.
That’s why in Sendmarc, they will host this for you, allowing you to control the configuration modes and leave the max-age configuration to them.
MTA-STS and the future of DMARC
Still with me? Although this has been a very technical article, I’m hoping I’ve shared some useful insights into MTA-STS.
