E-Mail | MTA-STS

I wrote before already about SPF, DKIM and DMARC, but MTA-STS is also an addition to the security of you e-mail.

MTA-STS stands for Mail Transfer Agent Strict Transport Security. It’s a security protocol that allows domain owners to enforce the use of Transport Layer Security (TLS) encryption when exchanging emails with other mail servers. Essentially, MTA-STS is a mechanism to protect against man-in-the-middle (MITM) attacks, which can compromise email security and privacy. By requiring TLS encryption and enforcing a strict security policy, MTA-STS helps prevent attackers from intercepting and reading email messages, as well as altering or injecting malicious content into those messages.

Why?

Email security breaches can adversely affect an individual or an organization’s reputation, privacy, and finances. MTA-STS is a potent email security protocol that aims to mitigate email security issues. By implementing MTA-STS, domains can ensure that their email transmission is encrypted and secure, eliminating the chances of email breaches. Additionally, MTA-STS also encourages the use of valid TLS certificates, which improves the domain’s trustworthiness.

• Protect against man-in-the-middle attacks: MTA-STS helps prevent attackers from intercepting and altering your email messages, which can compromise the confidentiality and integrity of your communications.
• Enforce the use of TLS encryption: MTA-STS enforces the use of TLS encryption, which is essential for protecting sensitive information from unauthorised access.
• Comply with industry standards: MTA-STS is becoming an industry standard for email security, so implementing it can help ensure compliance with regulations and best practices.
• Improve email deliverability: MTA-STS can improve email deliverability by reducing the likelihood of email messages being rejected or marked as spam.
• Easy to implement: MTA-STS is relatively easy to implement and configure, especially for domain owners who already have experience managing DNS records.

How does MTA-STS work?

MTA-STS requires a domain to add a DNS record called “MTA-STS.” This record contains straight forward instructions to remote mails servers regarding email transmission. A domain policy in MTA-STS can be one of the following:

• Policy “None”: When “none” is set, it means that the domain doesn’t support MTA-STS, and the email transmission relies on SMTP standard protocols.
• Policy “Testing”: The domain is testing a new MTA-STS policy, and the mailservers don’t need to fully comply with the requirements.
• Policy “Enforce”: The domain has successfully implemented MTA-STS and enforces secure email connections.

When a remote mail server receives an email to send, it automatically checks whether the recipient domain has published an MTA-STS record or not. If an MTA-STS record is found, the mail server checks the domain’s policy for email transmission. If the domain policy is set to “none” or “testing,” the email transmission works on standard SMTP protocols. However, if “enforce” is set, the mail server checks whether the TLS certificate used by the sender domain is valid and issued by a trusted authority. If the TLS certificate is not valid, the email transmission fails, and the sender receives an error message.

TLS encryption:

Transport Layer Security (TLS) is an Internet Engineering Task Force (IETF) standard that encrypts messages between two email servers. With MTA-STS, both the sender and receiver mail servers must support TLS encryption for the email to be delivered. If either server does not support TLS, the email will not be delivered, and the sender will receive a non-delivery report (NDR) stating that the email could not be delivered.

Certificate validation:

The second mechanism MTA-STS uses is certificate validation. When an email server receives a message, it will check the DNS for the sender’s MTA-STS policy. It will then check if the server’s certificate matches the policy. If the certificates do not match or the policy is not published, the email will be rejected.

Setup MTA-STS

To set up MTA-STS, you need to follow these steps:

1. Generate a TLS certificate: You will need to generate a TLS certificate for your email domain. You can either purchase a certificate from a trusted certificate authority (CA) or use a free certificate from Let’s Encrypt.
2. Create a MTA-STS policy file: You need to create a policy file that defines your MTA-STS policy. This file should be named “mta-sts.txt” and should be hosted on your domain’s web server.
3. Publish MTA-STS policy: You need to publish your MTA-STS policy by adding a DNS record to your domain’s DNS server. This record should be a TXT record with the name “_mta-sts” and should contain the URL to your policy file.
4. Test MTA-STS policy: You should test your MTA-STS policy to ensure that it is working correctly. You can use the online MTA-STS testing tool to check if your policy is being correctly enforced.
5. Monitor MTA-STS logs: Monitor the logs to ensure that your policy is being correctly enforced and to troubleshoot any issues that arise.

In Microsoft 365 you can enable it easily with a few lines of code:

# connection
Connect-ExchangeOnline

# get transportrules
Get-transportRule

# enable MTA-STS
Enable-TransportRuleTransportRule <rule name> -RequireTLS $true -EnableSecureTransport $true

How to test MTA-STS?

First, you need to check if the domain you are testing has published an MTA-STS policy. You can do this by performing a DNS lookup for the TXT record “_mta-sts.domain.com”. If the record exists, the domain has enabled MTA-STS.
Next, you need to check the HTTPS certificate of the domain. You can do this by using tools like SSL Labs’ SSL Server Test or Qualys SSL Server Test. The test results will show if the server supports MTA-STS and if the certificate is valid.

You can check also with MTA-STS validator – Mailhardener tools to see if it is correct.

Alex ter Neuzen

IT Professional on a journey to discover the cloud platforms and become certified and an expert.
A Blog that follows the journey to get to the Cloud.

Azure Local | Azure Bicep | Azure Virtual Desktop | Powershell | Azure Certified | MCSA | Microsoft 365