What is MTA-STS (Mail Transfer Agent Strict Transport Security) and why do you need it?

 

We have heard so much about securing your outgoing emails, but the truth is, attackers can even enter your digital ecosystem through emails that are sent to your organization. This means your incoming emails are just as unsafe as your outbound ones. 

You might think that when an email is sent out, it reaches the receiving server directly (from Point A to Point B), but in reality, that’s not how an email travels. Before it reaches you, it travels through several intermediate servers on the internet. You can think of these as stops along the way. 

Even if one of these stops is not protected or encrypted properly, it can give an attacker a way to slip in. And once they manage to do that, they can read the email, change parts of it, or quietly redirect it somewhere else before it even reaches your inbox, all without your knowledge. 

This is why it is important that you protect your incoming emails just as you do for your outbound ones with SPF, DKIM, and DMARC. 

This is exactly why MTA-STS (Mail Transfer Agent Strict Transport Security) is an essential aspect of your email security strategy.  It makes sure that emails sent to your domain are delivered only over safe, encrypted connections and only to servers you trust. If those conditions aren’t met, the email won’t be delivered at all.

In this article, we will discuss what exactly MTA-STS is and why you need it in your security strategy to protect your incoming emails.

 

 

What is MTA-STS, and what led to its introduction?

In 1982, when SMTP (Simple Mail Transfer Protocol) was first introduced, it lacked any security measures to protect communications between mail transfer agents. This is a major loophole that attackers have leveraged time and again. Since the connection between two mail servers wasn’t required to be encrypted, attackers could intercept the communication, force it to downgrade to an insecure connection, or even reroute the email to a server they controlled.

To fill these gaps, a new command was added to this protocol— STARTTLS. This command allowed servers to upgrade an unencrypted connection to an encrypted one during the email transfer. In theory, this made communication between servers much safer.

But there was still a problem. STARTTLS was optional, which meant attackers could still interfere with the connection. This weakness is what led to the introduction of MTA-STS.

As per the policy stated in RFC 8461, MTA-STS adds a stronger layer of protection between your sending and receiving servers by ensuring that emails are sent through SMTP over TLS instead of an insecure SMTP connection. So, when you implement MTA-STS, you’re basically telling the servers that your system will only accept emails that arrive through a properly encrypted channel and from servers that have valid, trusted certificates.

This removes the vulnerability that STARTTLS introduces, since encryption is no longer optional. This way, you can also prevent man-in-the-middle attacks and ensure that only legitimate servers with valid certificates can send email to your domain.

 

 

How does MTA-STS work?

When someone sends you an email, the mail server first checks your DNS to see if you have implemented MTA-STS policy. If there is one, the server then downloads the policy file from your website. This file then tells the sender to use a secure, encrypted connection and to deliver the email only to the servers you trust. This helps the sender understand how exactly to deliver messages safely.

The server then tries to follow the policy you have configured. Let’s say, if it is able to set up a secure TLS connection with your email servers, the message is delivered normally. But if a secure connection cannot be established, the server stops the delivery instead of sending the email over an unsafe path.

This closes any gaps left by STARTTLS and prevents attackers from downgrading the connection or tampering with your email while it’s in transit.

 

What do you need for MTA-STS to work?

Implementing MTA-STS is not as complicated as it might sound. However, you’d still need to meet a few requirements for this standard to work properly. 

• A web server with HTTPS to host your MTA-STS policy file
• A DNS TXT record that tells other mail servers you support MTA-STS and where to find your policy
• Correct setup and regular checks to make sure everything stays updated and working properly

 

 

Why should you implement MTA-STS for your incoming emails?

The main goal of MTA-STS is not just to fill the gaps left by its predecessors but to ensure that even your incoming emails always travel through a safe, encrypted path.

Here’s why you should implement MTA-STS in your email security strategy:

 

Prevent man-in-the-middle attacks

If you don’t protect your domain with MTA-STS, your incoming emails will be delivered to you unencrypted. This means an attacker can easily intercept the message while it’s travelling between the servers. And once they gain access to the email, they can manipulate it to carry out their malicious intentions.

 

 

Enhance email privacy

By encrypting your incoming emails with MTA-STS, you can ensure that your emails aren’t read by any unauthorized parties while they are in transit. In fact, even if someone tries to intercept the message, they will not be able to read its content. 

 

Build trust with the senders

As a business owner, it is important that you show the senders that their emails reach you. By using MTA-STS, you signal that you protect their messages with secure, encrypted delivery, which helps build trust and confidence in your domain.

 

 

As a domain owner, it’s easy to think your responsibility is only to secure your outgoing emails, but that’s clearly not the case. It is important that both ends of your email communication are secure. You can ensure this by implementing the right security strategies and protocols. To protect your incoming emails, MTA-STS is the most reliable way to make sure they arrive over a safe, encrypted connection. 

Are you ready to protect your digital infrastructure from evolving cyber threats, but are not sure where to start? Get in touch with us.