How to Set Up MTA-STS and TLS-RPT: Stop Email Interception

Billions of emails move across the internet every day, and a significant portion of them still travel without enforced encryption. That scale alone makes email one of the most attractive targets for interception, where messages can be read or altered while in transit without either sender or recipient noticing.

The weakness lies in how email is delivered. SMTP relies on opportunistic encryption, which allows attackers to strip or tamper with the STARTTLS command and force a connection to fall back to plaintext. These SMTP downgrade attacks open the door to man-in-the-middle interception, letting attackers monitor traffic, capture sensitive content, or redirect messages through servers they control.

Contact us Book a demo

Table of Contents

    1. Mail Transfer Agent-Strict Transport Security (MTA-STS)
    2. Ensuring Encryption with MTA-STS
    3. The Anatomy of a MITM Attack
    4. The MTA-STS Policy File
    5. How to Publish the MTA-STS Policy File
    6. MTA-STS DNS Record
    7. Configuring MTA-STS for Your Domain
    8. Challenges of Manual MTA-STS Deployment
    9. How to Test and Validate Your MTA-STS Setup
    10. PowerDMARC’s Hosted MTA-STS Services
    11. SMTP TLS Reporting (TLS-RPT)
    12. Securing Email Transport with MTA-STS
    13. Frequently Asked Questions

Mail Transfer Agent-Strict Transport Security (MTA-STS) closes this gap by requiring encrypted TLS connections between sending and receiving mail servers and refusing delivery when a secure channel cannot be established. Instead of hoping encryption is used, MTA-STS enforces it, making it essential for organizations looking to set up MTA-STS as part of their email security strategy.

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

Ensuring Encryption with MTA-STS

Email is delivered between servers using SMTP, a protocol that supports encryption but does not require it by default. This creates an opening where messages may still be transmitted without protection. MTA-STS closes that gap by making encrypted delivery a requirement rather than an option.

To understand how encryption works during email delivery, consider a mail server sending a message to [email protected]. The sending Mail Transfer Agent (MTA) first performs a DNS query to retrieve the MX records for powerdmarc.com, identifying which mail servers are responsible for receiving the message. The sending MTA then connects to one of those servers and checks whether it supports TLS encryption using the STARTTLS command. If TLS is available, the email is sent over an encrypted connection. If it is not, the sending server fails to negotiate a secure connection and, without enforcement, may fall back to sending the message in plaintext.

MTA-STS changes this delivery behavior by enforcing strict security requirements during server-to-server communication:

MTA-STS instructs sending mail servers to deliver messages only over a TLS-encrypted connection. If encryption cannot be established, the message is not delivered at all. This removes the silent fallback to plaintext that makes interception possible.

The receiving mail server must present a valid TLS certificate, and the domain name on that certificate must match the domain defined in the MTA-STS policy. This ensures the sending server is communicating with the correct destination and not an impersonating host.

MTA-STS policies are retrieved over HTTPS from a secure web server. Fetching the policy through an encrypted and authenticated channel prevents attackers from modifying or spoofing policy instructions during transit.

By enforcing encryption and validating both certificates and policy instructions, MTA-STS blocks SMTP downgrade attacks that rely on stripping or altering the STARTTLS command. Sending servers no longer accept insecure fallbacks when a secure connection should exist.

hosted mta sts services
hosted MTA STS

MTA-STS is implemented by publishing a DNS record that directs sending mail servers to retrieve a policy file from a designated subdomain. The policy file is accessed over HTTPS, validated using TLS certificates, and contains the approved hostnames of the recipient’s mail servers. The protocol instructs sending SMTP servers to require an encrypted connection and to verify that the domain listed on the TLS certificate matches the domain defined in the policy file. If MTA-STS is enforced, in case an encrypted channel cannot be negotiated, the message is not delivered at all.

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

Warning signs

MITM attacks often operate quietly, but certain patterns can signal that something is wrong during email delivery. One common warning sign is unexpected delivery failures or delays when communicating with specific domains, especially when those domains previously accepted messages without issue. Sudden increases in TLS negotiation failures, fallback to unencrypted connections, or repeated STARTTLS errors can also point to interference during transmission.

Another indicator is inconsistent mail routing behavior. Emails may appear to pass through unfamiliar servers, or logs may show connections to hosts that do not match the intended recipient’s published MX records. In more advanced cases, messages arrive altered, truncated, or forwarded through intermediate systems without a clear explanation.

Detection relies heavily on visibility. Monitoring SMTP connection logs helps identify repeated encryption failures or certificate mismatches. TLS-RPT adds another layer by providing reports when servers fail to establish secure TLS connections, flagging issues such as downgrade attempts, invalid certificates, or policy enforcement failures. 

All these signals help surface MITM activity that would otherwise remain hidden during normal email flow.

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

How to Publish 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 policy file must be served over an HTTPS-enabled web server to ensure it is retrieved securely by sending mail servers.

  • Use a certificate issued by a trusted certificate authority

    The server certificate must be signed and validated by a third-party root certificate authority so that sending MTAs can authenticate the source of the policy.

  • Host the file on a dedicated mta-sts subdomain

    A public web server must be set up with the subdomain mta-sts added to your domain, which is used exclusively for publishing the MTA-STS policy.

  • Place the policy file in the required directory

    The policy file must be named mta-sts.txt and published inside the .well-known directory on the mta-sts subdomain.

  • Ensure the policy file is publicly accessible at the correct URL

    Sending MTAs must be able to retrieve the file from a location formatted as
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt without authentication or redirects.

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 of Manual MTA-STS Deployment

Deploying MTA-STS manually involves more than publishing a single DNS record. It requires coordinating web infrastructure, certificates, policies, and ongoing maintenance, which can introduce several challenges if not managed carefully.

  • Requirement for an HTTPS-enabled web server

    MTA-STS policies must be hosted on a publicly accessible HTTPS server with a valid TLS certificate. This requires provisioning infrastructure, configuring TLS correctly, renewing certificates on time, and ensuring high availability.

    Solution: Organizations with limited web infrastructure may reduce complexity by using a hosted MTA-STS service that manages servers and certificates automatically.

  • Ongoing policy file maintenance

    Any change to the mail server configuration requires updating the MTA-STS policy file. If the file is outdated, legitimate emails may fail delivery once enforcement is enabled.

    Solution: Centralized policy management or automated tools help ensure updates are applied immediately and accurately.

  • DNS record updates and version control

    The MTA-STS TXT record must be updated with a new id value every time the policy changes. Missing or incorrect updates can delay policy refresh and cause inconsistent enforcement.

    Solution: Automation reduces the risk of human error and keeps DNS records aligned with policy changes.

  • Limited visibility into delivery failures

    Without TLS-RPT, encryption-related delivery issues may go undetected. Even with TLS-RPT enabled, raw JSON reports can be difficult to interpret without specialized knowledge.

    Solution: Reporting platforms that parse and visualize TLS reports make it easier to detect failures and respond quickly.

  • Higher operational overhead and coordination effort

    Manual deployment requires coordination between DNS, email, and security teams, increasing the risk of misconfiguration and delays.

    Solution: Teams should evaluate whether they have the time and expertise to maintain MTA-STS long term or whether a managed approach better fits their operational priorities.

How to Test and Validate Your MTA-STS Setup

Testing is a critical step before moving an MTA-STS policy into enforcement mode. Once enforcement is enabled, sending servers are instructed to reject email delivery if a secure TLS connection cannot be established. Without proper validation, configuration errors can lead to unintended message loss, making careful testing essential for maintaining reliable email delivery.

  • DNS propagation checks

    After publishing the MTA-STS TXT record and related DNS entries, confirm that they are resolving correctly across public DNS resolvers. Incomplete or delayed propagation can cause sending servers to rely on outdated or cached policies, resulting in inconsistent behavior during delivery.

  • Policy file accessibility

    Verify that the MTA-STS policy file is accessible over HTTPS at the expected location on the mta-sts subdomain. The file should be reachable without redirects, authentication requirements, or certificate errors. Any interruption in access can prevent sending servers from retrieving the policy.

  • TLS support verification

    Confirm that all MX hosts listed in the policy support TLS and present valid certificates that align with policy requirements. Successful TLS negotiation ensures that encrypted connections can be established consistently once enforcement is enabled.

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 when a secure connection cannot be established. However, one problem remains unaddressed: how to notify domain owners when remote servers experience email delivery issues caused by TLS failures. This is where TLS-RPT comes into play, complementing MTA-STS by providing diagnostic reports that support monitoring and troubleshooting of server communication issues, such as expired TLS certificates, mail server misconfigurations, or failed TLS negotiations.

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

What TLS-RPT does

TLS-RPT is designed to report email delivery failures related to TLS encryption between mail servers. Its primary purpose is to give domain owners visibility into situations where messages cannot be delivered securely, helping identify problems that would otherwise remain hidden during normal SMTP communication.

Through these reports, TLS-RPT helps identify issues such as failed TLS negotiations between sending and receiving servers, expired or invalid TLS certificates, and configuration errors on either side of the mail exchange. This insight allows administrators to pinpoint where encryption breaks down and take corrective action.

TLS-RPT reports are generated and sent by compliant Mail Transfer Agents, typically on a daily basis, providing ongoing visibility into the health of secure email delivery.

json charts

How to enable it

TLS-RPT is enabled by publishing a DNS TXT record at the required _smtp._tls location for your domain. This record signals support for TLS reporting and specifies the destination where diagnostic reports should be delivered.

The TXT record defines one or more reporting addresses, typically email or HTTPS endpoints, that compliant sending mail servers use to send TLS-RPT data. Once the record is in place, reporting begins automatically without any changes to mail server behavior.

TLS-RPT can be configured manually by adding the TXT record directly to DNS or through platforms that provide a UI-based setup. Using a managed interface simplifies deployment by handling record creation and validation for you, reducing the risk of syntax errors or misconfiguration.

Read more

Securing Email Transport with MTA-STS

Email remains a critical communication channel, but without enforced encryption, it is vulnerable to downgrade and MITM attacks that can expose message content or disrupt delivery. Protecting email in transit is essential for preserving confidentiality and maintaining trust between sending and receiving mail servers.

MTA-STS strengthens email transport by requiring TLS encryption and rejecting delivery when secure connections cannot be established. By removing the fallback to unencrypted communication, it helps ensure that messages are delivered only through authenticated and protected channels, improving consistency and reliability across server-to-server exchanges.

Successful adoption of MTA-STS depends on careful preparation. Policies must be configured accurately, supporting infrastructure must be validated, and enforcement should be introduced gradually after thorough testing. Skipping these steps can result in unintended delivery failures, particularly when policies are moved too quickly into enforce mode.

Before enabling enforcement, organizations should review their current email security posture, confirm TLS readiness across all mail servers, and ensure that DNS and policy files are correctly published. Ongoing monitoring and periodic validation remain important over time, as server configurations change and certificates expire, helping ensure that MTA-STS policies continue to protect email delivery effectively.

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