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.

SMTP downgrade attack

Ensuring Encryption with MTA-STS

Whenever you send emails using the SMTP server of your  email service providers like Gmail or Microsoft, the emails are transferred from the sending server to the receiving server through Simple Mail Transfer Protocol (SMTP). However, SMTP allows opportunistic encryption, implying that the communication between SMTP servers may or may not be encrypted to avoid manipulation or eavesdropping on email content. MTA-STS is published using HTTPS, protecting it against MITM attacks.

MTA-STS secures email delivery by: 

  • Enforcing TLS encryption

  • Serving the MX records from an HTTPS-secure server

hosted mta sts services
hosted MTA STS

MTA-STS protocol is deployed by having a DNS record that specifies that a mail server can fetch a policy file from a specific subdomain. This policy file is fetched via HTTPS and authenticated with certificates, along with the list of names of the recipients’ mail servers. The protocol specifies to an SMTP server that the communication with the other SMTP server must be encrypted and that the domain name on the certificate should match the domain of the policy file. If MTA-STS is enforced, in case an encrypted channel cannot be negotiated, the message is not delivered at all.

The MTA-STS Policy File

The MTA-STS policy file is essentially a simple text file, which looks like the following:

version: STSv1
mode: enforce
mx: mx1.powerdmarc.com
mx: mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age: 604800

Note: The version field must be included at the beginning of the text file while other fields can be incorporated in any order.

The policy file uses key-value pairing with each value encoded on a separate line in the text file as shown above. The size of this file can extend up to 64 KB. The name of the policy file must be mta-sts.txt. Policy files are required to be updated every time you add or alter mail servers in your domain.

Note: Setting MTA-STS at enforce mode can cause some emails not to be delivered to you. Therefore it is advisable to set the policy mode to testing instead and opt for a low max_age to ensure that everything is working correctly before shifting to enforce policy. We recommend setting up TLS-RPT for your policy in testing mode as well to get notified in case emails are sent in plaintext. 

MTA-STS-Policy

Publishing the MTA-STS Policy File

In order to publish the MTA-STS policy file, the web server that hosts your file must:

  • Support HTTPS/SSL
  • The server certificate must be signed and validated by a third-party root certificate authority.

In order to publish a policy file for your domain, you should set up a public web server with the subdomain “mta-sts” added to your domain.. The created policy file must be published in the .well-known directory created in the subdomain. The URL for your uploaded MTA-STS policy file might appear something like this:

https://mta-sts.powerdmarc.com/.well-known/mta-sts.txt

hosted MTA STS

MTA-STS DNS Record

A TXT DNS record for MTA-STS is published on the DNS of your domain to specify that your domain supports MTA-STS protocol and to signal for refreshing the cached values in the MTAs in case the policy is altered. The MTA-STS DNS record is placed at subdomain _mta-sts like in: _mta-sts.powerdmarc.com. The TXT record must commence with v=STSv1, and the “id” value can contain up to 32 alphanumeric characters, included in the following way:

 v=STSv1; id=30271001S00T000;

Note: The TXT record id value must be updated to a new value every time you make changes to the policy. 

The MTA-STS DNS Record is used to: 

  • Specify support for MTA-STS for the domain
  • Signal the MTA to re-fetch the policy over HTTPS in case the policy is altered

Note that with the MTA-STS TXT DNS record, the policy file can be stored by MTAs for a longer time period without having to re-fetch the policy unless it has been altered, while still performing a DNS query every time an email is received for the domain.

Configuring MTA-STS for Your Domain

In order to enable MTA-STS for your domain you would be required to:

  • Add a cname type DNS record at mta-sts.example.com, directed towards the HTTPS enabled web server that is hosting the MTA-STS policy file.

  • Add a txt or cname type DNS record at _mta-sts.example.com which specifies support for MTA-STS for your domain.

  • Set up an HTTPS enabled web server with a valid certificate for your domain.

  • Enable SMTP TLS Reporting for your domain to detect issues in email delivery due to failures in TLS encryption.

spf record lookup icon powerdmarc

Challenges Faced While Manually Deploying MTA-STS

MTA-STS requires an HTTPS-enabled web server with a valid certificate, DNS records, and constant maintenance, which makes the deployment process lengthy, time-consuming and complicated. This is why we at PowerDMARC help you manage most things in the background by just publishing three CNAME records in your domain’s DNS.

PowerDMARC’s Hosted MTA-STS Services

PowerDMARC makes your life a whole lot easier by handling all of that for you, completely in the background. Once we help you set it up, you never even have to think about it again.

  • We help you publish your cname records with just a few clicks

  • We take the responsibility of maintaining the web server and hosting the certificates

  • Through our hosted MTA-STS services, deployment on your part is reduced to simply publishing a  few DNS records

  • You can make MTA-STS policy changes instantly and with ease, through the PowerDMARC dashboard, without having to manually make changes to the DNS

  • PowerDMARC’s hosted MTA-STS services are RFC compliant and support the latest TLS standards

  • From generating certificates and MTA-STS policy file to policy enforcement, we help you evade the tremendous complexities involved in adopting the protocol

SMTP TLS Reporting (TLS-RPT)

In order to make the connection between two communicating SMTP servers more secure and encrypted over TLS, MTA-STS was introduced to enforce encryption and prevent emails from being delivered in cleartext, in case either of the servers does not support TLS. However, one problem still remains unaddressed, that is: How to notify domain owners if remote servers are facing issues in email delivery due to failure in TLS encryption? Here is where TLS-RPT comes into play, providing diagnostic reports in order to enable the monitoring and troubleshooting of issues in server communications, such as expired TLS certificates, misconfigurations in email servers, or failure in negotiating a secure connection due to lack of support for TLS encryption.

TLS Reports help to detect and respond to issues in email delivery through a reporting mechanism in the form of JSON files. These JSON files can be complicated and indecipherable for a non-technical person.

PowerDMARC helps to simplify the JSON files in the form of simple. comprehensive and readable documents with charts and tables for your convenience. The diagnostic reports for your domain are also displayed in two formats on the PowerDMARC dashboard: per result and per sending source.

powerdmarc tls rpt
json charts

Enabling TLS-RPT for Your Domain

The process of enabling SMTP TLS Reporting is quite simple. All you need to do in order to enable it is add a TXT DNS record at the correct location, prefixing _smtp._tls. to your domain name. With PowerDMARC however, this can be setup directly from the PowerDMARC UI without you having to make any changes to your DNS!

As soon as you enable TLS-RPT, acquiescent Mail Transfer Agents will begin sending diagnostic reports regarding email delivery issues between communicating servers to the designated email domain. The reports are typically sent once a day, covering and conveying the MTA-STS policies observed by senders, traffic statistics as well as information on failure or issues in email delivery.

Read more

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.

Schedule a demo today
secure email powerdmarc

Start 15-day trial Book a demo