Important Alert: Google and Yahoo will require DMARC starting from April 2024.
Read more

MTA-STS and TLS-RPT Implementation Guide

Welcome to your detailed handbook on MTA-STS and TLS-RPT to get hands-on knowledge about the protocols and their functionalities.

Contact us Book a demo

Table of Contents

  1. What is Mail Transfer Agent-Strict Transport Security (MTA-STS)?
  2. How does MTA-STS ensure encryption of messages in transit?
  3. Breaking down the anatomy of a MITM Attack
  4. How does  MTA-STS ensure TLS encryption?
  5. What is the MTA-STS Policy File?
  6. How to publish the MTA-STS Policy File?
  7. What is MTA-STS DNS Record?
  8. How to deploy MTA-STS?
  9. What are the challenges faced while manually deploying MTA-STS?
  10. PowerDMARC’s Hosted MTA-STS Services
  11. What is SMTP TLS Reporting (TLS-RPT)?
  12. How to enable TLS-RPT for your domain?
  13. Frequently Asked Questions
encryption tls

Mail Transfer Agent-Strict Transport Security (MTA-STS)

MTA-STS, much like what the name suggests, is a protocol that enables encrypted transport of messages between two SMTP mail servers. MTA-STS specifies to sending servers that emails should only be sent over a TLS encrypted connection, and should not be delivered at all in case a secured connection is not established via the STARTTLS command. By enhancing the security of emails in transit, MTA-STS helps in mitigating Man-In-The-Middle attacks (MITM) such as SMTP downgrade attacks, and DNS spoofing attacks.

Read more

How Does MTA-STS Ensure Encryption of Messages in Transit?

Let’s take a simple example to understand how messages get encrypted during email flow. If an MTA is sending  an email to [email protected], the MTA performs a DNS query to find out which MTAs the email must be sent to. The DNS request is sent to fetch the MX records of powerdmarc.com. The sending MTA subsequently connects to the receiving MTA found in the DNS query result, enquiring whether this receiving server supports TLS encryption. If it does, the email is sent over an encrypted connection, however, if it does not, the sending MTA fails to negotiate a secured connection and sends the email in plaintext.

Sending emails over an unencrypted pathway paves the way to pervasive monitoring attacks like MITM and SMTP downgrade. Let’s find out how:

Breaking Down the Anatomy of a MITM Attack

Essentially, a MITM attack takes place when an attacker replaces or deletes the STARTTLS command to make the secured connection rollback to an unsecured one, without TLS encryption. This is referred to as  a downgrade attack. After successfully performing a downgrade attack, the attacker can access and view the email content without hindrances.

A MITM attacker can also replace the MX records in the DNS query response with a mail server that they have access to and are in control of. The mail transfer agent in that case delivers the email to the server of the attacker, enabling him to access and tamper with the email content. The email can subsequently be forwarded to the intended recipient’s server, without being detected. This is known as a DNS spoofing attack.

Frequently Asked Questions

PowerDMARC’s control panel allows you to automatically set up MTA-STS and TLS-RPT for your domain by publishing just three CNAME records in your domain’s DNS. From hosting MTAS-STS policy files and certificates to maintaining the web server, we take care of it all in the background without you having to make any changes to your DNS. Deployment of MTA-STS on your part with PowerDMARC is reduced to just a few clicks.

You can deploy and manage MTA-STS for all your domains from your PowerDMARC account, through a single pane of glass. In case any of those domains are using receiving mail servers that do not support STARTTLS, it will reflect in your TLS reports provided you have TLS-RPT enabled for those domains.

It is always advisable to set your MTA-STS policy mode to testing during the initial phases of deployment so that you can monitor activities and gain visibility into your email ecosystem before shifting to a more aggressive policy like enforce. This way even if the emails are not sent over a TLS encrypted connection, they would still be sent in plaintext.  However, make sure you enable TLS-RPT to get notified if that happens. 

TLS-RPT is an extensive reporting mechanism that allows you to get notified in case a secured connection could not be established and the email failed to be delivered to you . This helps you detect issues in email delivery or email delivered over an unsecured connection so that you can promptly mitigate and resolve them.

You must note that while MTA-STS ensures that emails are transferred over a TLS encrypted connection, in case a secured connection is not negotiated the email might fail to get delivered at all. This however, is necessary as it ensures that email is not delivered over an unencrypted pathway. To avoid such issues, it is advisable to set up an MTA-STS policy on a testing mode and enable TLS-RPT for your domain initially, before proceeding to the MTA-STS enforce mode. 

You can easily change your MTA-STS mode from the PowerMTA-STS dashboard by selecting your desired policy mode and saving changes without the requirement of making any changes to your DNS.

You can turn off MTA-STS for your domain by either setting the policy mode to none, thereby specifying to MTAs that your domain doesn’t support the protocol, or by deleting your MTA-STS DNS TXT record. 

The MX records for the MTA-STS policy file should include the entries for all receiving mail servers being utilized by your domain.