The estimated reading time 3 minutes
Several days ago, the BSI published a good article on the topic of email security and modern email infrastructures.
https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/BSI-CS_155.pdf
This prompted me to write this article.
Since the SMTP protocol was designed in the 1980s and security was not a major concern at that time, we need to continuously develop mechanisms to adapt this protocol to today’s requirements. One of these mechanisms is MTA-STS (Mail Transfer Agent-Strict Transport Security).
Simply put, MTA-STS enforces a TLS connection from mail server to mail server. The receiving mail server can inform the sending server that TLS is not optional but mandatory. This is achieved through a combination of DNS and HTTPS. Essentially, this ensures that emails are not exchanged unencrypted, as most mail servers use so-called “Opportunistic TLS.” In this case, a common denominator is established during the TLS negotiation, if necessary, at a low security level or even without TLS if the recipient or sender does not support TLS.
This can easily lead to man-in-the-middle attacks, and data can be intercepted. Here is a good video with further explanation.”
There’s also a good article on MTA-STS in Microsoft Learn that describes the setup in detail. See here.
Now, let’s move on to the MTA-STS mechanism:
Prerequisites
- Access to the webspace
- Access to DNS management
- Check if the mail server supports TLS with the corresponding certificate
- Possibly set up an email address for reporting
Implementation:
First, a subdomain must be created on the web server, in my case with the provider, and a subfolder named “.well-known”. The TXT (policy file) must then be placed here.
In the end, a finished link must be created that presents the TXT file:Â https://mta-sts.it-koehler.com/.well-known/mta-sts.txt
For this step, I use FileZilla for the upload, but it can also be done with any other tool or even with Windows Explorer.
content of this textfile looks like this:
- Mode: NONE, TESTING, ENFORCE
- MX: The MX record is the domain’s configured MX record.
- MAX_AGE: The duration for which the policy is stored by sending servers, in seconds.
version: STSv1 mode: enforce mx: *.mail.protection.outlook.com max_age: 604800
In my case, I adopted the Microsoft standard and set the validity period to one week.Â
Note: If there are issues with TLS, sending mail servers might not be able to send for the specified time (Max Age), as a policy update will only be fetched after the period expires.
Now, let’s proceed with the DNS entries for the domain, in my case, it-koehler.com.
v=STSv1; id=20250530T104127Z;
The ID can be created manually or, in my case, it was generated by Copilot.
Reporting is definitely recommended here to quickly identify any potential errors.
v=TLSRPTv1; rua=mailto:TLSRPT@it-koehler.com
Once the entries are published on the internet, a simple check can be performed using MXTOOLBOX.
or you can use https://www.hardenize.com/
I hope this article sheds some light on the topic and helps to further secure mail servers. In general, this method offers quite good protection, but DANE for incoming emails would be a bit better if DNSSEC is available.
If you liked the article, feel free to click “Helpful.” Otherwise, I appreciate constructive comments.
