On the face of it, sending out emails is as simple as typing the text and pressing Send. However, the background processes aren’t that simple. It takes a lot of hardware, software, networking, and protocols to deliver that email to the other end, securely.
Email authentication mechanisms like SPF, DKIM, and DMARC play a significant role in ensuring that only legitimate emails reach their end destinations, while spam and spoofed emails are filtered out. However, these do not ensure end-to-end email security, since the emails are vulnerable to Man-in-the-Middle attacks when transferring between mail servers using SMTP.
For this purpose, a relatively newer technology has been introduced known as Mail Transfer Agent – Strict Transport Security (MTA-STS). The MTA-STS technology aims to create a Transport Layer Security (TLS) tunnel between mail servers and ensure that those servers always use TLS when transporting mail. Assurity of TLS use when transferring mail does not eliminate but reduces the risk of outside threats.
Table of Contents
What is MTA-STS
The function of MTA-STS is to verify that the mail servers use a secure TLS connection when sending mail to you. It declares support for a TLS connection, so that it is used every time for the configured domain.
MTA-STS is a combination of a defined policy, coupled with a DNS TXT record, which works in tandem to validate a TLS connection. Moreover, with the policy defined, you can control whether emails not sent through a TLS connection should be rejected or sent to the destination inbox.
Additionally, like DMARC reporting, you can also configure MTA-STS reports that inform you about incoming emails not sent through secure channels. This is known as TLS Reporting.
Why need MTA-STS?
MTA-STS ensures the mail server that it is not communicating with an imposter, but with the authorized SMTP server authorized to transfer the email. This would then also ensure that the contents of the mail are untampered (which is verified by DKIM’s digital signature).
While no security measure is 100% foolproof, MTA-STS coupled, when coupled with TLS reporting, adds an extra layer of security. The older protocol in place of MTA-STS, which was STARTTLS, did not always ensure TLS encryption for each connection, leaving wiggle room for attackers. MTA-STS resolves that issue, preventing downgrade attacks.
Moreover, it also eliminates Man-in-the-Middle attacks and keeps the contents of the mail and its sender private, and unexploited. Additionally, it also addresses the issue of expired TLS certificates.
On the other hand, TLS reporting also adds a few benefits. TLS reporting informs you about email connections that succeeded or failed and helps diagnose issues related to TLS negotiation.
Requirements for MTA-STS
Although it is a great email security technology, not everyone can go ahead and configure MTA-STS for their domain. Certain conditions need to be met by the mail server before you can configure MTA-STS, which are as follows:
- A server that can accept mail transfers via TLS connection
- Uses at least TLS version 1.2
- The TLS certificates should:
- Be up-to-date
- Have the same servers mentioned in your MX records
- Be trusted by a root certificate authority
If your mail server satisfies these requirements, then you can configure MTA-STS on it to enhance your email security.
How MTA-STS works
As mentioned earlier, MTA-STS works together with a DNS record and a defined policy. However, there is more to it than meets the eye. Bear with me as things might get complicated, but I will try to explain them to you in a way that can be easily understood.
There are 3 parts of a correctly-configured MTA-STS standard:
- A DNS TXT record that defines that a MTA-STS policy is configured.
- A DNS TXT record defines the email address to receive the reports for failed TLS connections. Note that this TXT record is optional and only required if you want TLS reporting.
- A plain-text file that controls how emails delivered without TLS connection are handled, is publically available, and is defined on the hosting instead of the DNS server. This is the policy file.
With this information, it will be easier for us to understand how MTA-STS works.
When your mail server is receiving an email, it performs a DNS record lookup for the sending domain using its header. It finds that the domain supports a TLS connection, and initiates a TLS handshake. Simultaneously, the MTA-STS DNS record specifies where the mail server can fetch a policy file. The policy file is fetched via HTTPS and authenticated with certificates.
When the policy file is retrieved, the sending SMTP server checks the recipient domain’s MTA-STS policy. If the TLS connection is successful, and if the policy allows, the email is forwarded to the recipient’s inbox. If the TL connection fails and the policy is configured to reject it, the email is rejected.
Meanwhile, the TLS reports will continue to provide feedback on successful and failed connections, helping administrators identify issues, if configured.
This explains the topological function of MTA-STS. This is further clarified when you attempt to configure MTA-STS for your domain. I have split the configuration steps for MTa-STS DNS records and the policy file for better understanding.
How to configure MTA-STS DNS records
As mentioned earlier, the MTA-STS had a two-part DNS record. One defines that the server supports the TLS connection, while the other specifies where to send the TLS reports, which is optional.
The former DNS record which defines that the server supports TLS connections is named as follows:
_mta-sts.yourdomain.com
“_mta.sts” has the following tags used to define its value:
| Tag | Description |
| v | Defines the MTA-STS version. The only valid version at the moment is “STSv1“ |
| id | Is an alphanumeric string up to 32 alphanumerics long, used to track policy. If not provided by your email service provider, you can make it up with a unique number, or use a MTA-STS record generator. |
The other MTA-STS DNS record used to set up TLS reporting has the following naming nomenclature:
_smtp.tls.yourdomain.com
“_smtp.tls” has the following tags for defining its values:
| Tag | Description |
| v | Defines the TLS report version. The only valid version at the moment is “TLSRPTv1“. |
| rua | Defines the email address to receive the TLS reports. “rua” is followed by “mailto:”, which is followed by the email address |
To configure these on your DNS, you can use these simple steps:
Note: The DNS server can be different for everyone, therefore, the steps and screenshots may vary. Nonetheless, the same logic applies.
-
Log into your DNS server as an administrator.
-
Click “Add Record” and then click “Add TXT Record“.
Add a new TXT record -
Enter the name for the MTA-STS record using your domain name, such as this:
_mta-sts.yourdomain.com
Enter the MTA-STS record name -
Now use the following syntax while replacing the variables and paste it into the Record field:
Remember to replace [YourID] with an ID provided by your email service provider, or generate one yourself.
v=STSv1; id=[YourID]
Enter the value for the MTA-STS record -
[Optional] You may adjust the Time To Live (TTL) value, which is actually how long the record will be cached for.
-
When done, click Save Record.
-
[Optional] You may repeat the steps above and use the following TXT file name and values to also generate a TLS report DNS record:
Name:
_smtp.tls.yourdomain.com
Value:
v=TLSRPv1; rua=mailto:[EmailAddress]
Configure MTA-STS TLS Reporting DNS record -
Click “Save Record” when done.
With the completion of these steps, you will have successfully configured the MTA-STS records for your domain. However, you must still configure the MTA-STS policy on the hosting.
How to configure MTA-STS Policy Text File
As mentioned earlier, the MTA-STS records fetch the TLS policy from a plain text file stored on your domain’s server. Before we configure this file, there are a few rules you must understand:
- The MTA-STS policy file has the naming nomenclature of: “mta-sts.txt“
- The policy file is always stored/created at the path: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
To abide by these rules, you might need to create the subdomain “mta-sts.yourdomain.com“, if not already exist. Moreover, you might also need to create the “.well-known” folder in the subdomain, if not already exist.
Once both of these conditions are met you may continue to create the plain text file which defines the MTA-STS policy. Before you do, here are the tags used inside the policy and what they mean:
| Tag | Example | Description |
| version | version: STSv1 | Defines the STS version. At the moment, only “STSv1” is a valid value. |
| mode | mode: enforce | Defines how to deal with emails received over non-TLS medium. Acceptable options are none, enforce, and testing. |
| mx | mx: itechtics.org | Defines the Mail Exchange server for your domain. You may add multiple mx entries if more than one mx records exist. |
| max_age | max_age: 86400 | Indicates the cached duration for the policy, after an update is required. The number is expressed in seconds and should be between 604,800 and 1,209,600 (1–2 weeks) for testing mode; and between 24 hours (86,400 seconds) and 31,557,600 (one year) for enforce mode. |
Most of the tags for the MTA-STS policy file are explanatory using the table above, except for the values of the “mode” tag. This is what each of those values means:
- testing: The emails that fail to pass the TLS won’t be blocked, but you’ll be able to gather data on them using TLS reports.
- enforce: In this mode, failing the TLS means that the emails will be rejected. You’ll continue to receive TLS reports if configured.
- none: The none policy in your MTA-STS file means fully disabling the policy.
With this information, you should now be able to configure your MTA-STS policy, which should look something like the following:
version: STSv1 mode: enforce mx: itechtics.org mx: itechtics.com max_age: 86400
If the mta-sts.txt file is configured correctly inside the subdomain, you should be able to access it via a web browser, like this:
After configuring both the MTA-STS DNS records and the policy, wait for a while for the configuration to propagate, and then it should be configured correctly.
Closing words
As you would have understood by now, communication via email involves several mechanisms, protocols, and processes. We have already discussed the authentication mechanisms in place which include SPF, DKIM, and DMARC.
One additional receiver-end standard of authentication is Brand Indicator Message Identification (BIMI), which adds brand logos to authentic emails. With that, MTA-STS also provides a security pathway for emails so that attackers do not manipulate or capture them.
Together, these processes work in tandem to ensure that you receive untempered, authentic emails and that the spam and spoofed emails do not reach you or your organization, reducing the risk of phishing attempts.
