MTA-STS and TLS-RPT Explained: Securing Email in Transit

You have set up SPF, DKIM, and DMARC to authenticate your emails. But there is another attack vector that most senders overlook entirely: the connection between mail servers itself. When Server A sends an email to Server B, the SMTP handshake can be intercepted and downgraded to plaintext by a man-in-the-middle attacker, even if both servers support TLS encryption.

This is the problem that MTA-STS solves. Defined in RFC 8461, MTA-STS allows a domain to publish a policy declaring that all inbound email must be delivered over an encrypted, authenticated TLS connection. If a sending server cannot establish a secure connection, it must refuse to deliver the message rather than falling back to plaintext.

In this guide, we will explain how MTA-STS works, walk through the deployment process step by step, and cover how to use TLS-RPT to monitor your transport security.

The STARTTLS Problem

STARTTLS is the SMTP extension that upgrades a plaintext connection to an encrypted one. When two mail servers connect, the receiving server advertises 250 STARTTLS in its EHLO response, and the sending server can choose to upgrade the connection to TLS before transmitting the message.

The problem is that STARTTLS is opportunistic. This means:

• The EHLO handshake happens in plaintext, so an attacker positioned between the two servers can strip the STARTTLS advertisement from the response.
• The sending server sees no STARTTLS offer, assumes the receiving server does not support encryption, and sends the email in plaintext.
• Neither server knows the connection was tampered with. This is called a STARTTLS downgrade attack.

Additionally, even when STARTTLS is used, the sending server does not typically validate the receiving server's TLS certificate. An attacker could present a forged certificate and intercept the "encrypted" traffic. This combination of optional encryption and missing certificate validation makes standard STARTTLS vulnerable to interception.

What Is MTA-STS?

MTA-STS is a protocol that allows a receiving domain to publish a strict policy requiring that all inbound SMTP connections use TLS with a valid, trusted certificate. Unlike opportunistic STARTTLS, MTA-STS is not optional once deployed. If a sending server supports MTA-STS (and all major providers do), it must either establish a verified TLS connection or refuse to deliver the message.

MTA-STS has two components that work together:

1. A DNS TXT record at _mta-sts.yourdomain.com that advertises the domain supports MTA-STS and includes a version ID
2. A policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that specifies the enforcement mode and authorized MX hosts

MTA-STS Policy Modes

The MTA-STS policy supports three modes:

How to Set Up MTA-STS

Step 1: Create the Policy File

Create a plain text file named mta-sts.txt with the following content:

version: STSv1
mode: testing
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
max_age: 604800

Each field serves a specific purpose:

• version: Must be STSv1 (the only valid version)
• mode: Start with testing, upgrade to enforce after validation
• mx: List each authorized MX host on its own line. Only these hosts will be accepted for delivery.
• max_age: How long (in seconds) sending servers should cache this policy. 604800 = 7 days.

Step 2: Host the Policy File

The policy file must be accessible at this exact URL:

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

Requirements for the web server hosting this file:

• Must serve over HTTPS (not HTTP)
• TLS certificate must be from a trusted Certificate Authority (not self-signed)
• The mta-sts subdomain needs a DNS A or CNAME record pointing to the web server
• Content-Type should be text/plain

Step 3: Publish the DNS TXT Record

Add a TXT record at _mta-sts.yourdomain.com:

_mta-sts.yourdomain.com. IN TXT "v=STSv1; id=20250226T120000;"

The id value must be unique and should change every time you update the policy file. A timestamp format works well. When sending servers see a new id, they re-fetch the policy file to pick up your changes.

What Is TLS-RPT?

TLS-RPT (SMTP TLS Reporting), defined in RFC 8460, is a companion protocol that provides visibility into TLS connection outcomes. It works very similarly to DMARC aggregate reporting: sending mail servers generate daily JSON reports about their attempts to establish secure connections with your domain and email them to an address you specify.

These reports include:

• Total count of successful TLS sessions
• Total count of failed TLS sessions
• Specific failure details: certificate expired, certificate hostname mismatch, STARTTLS not supported, MTA-STS policy validation failure
• The sending server IP addresses involved in each failure

Setting Up TLS-RPT

Add a DNS TXT record at _smtp._tls.yourdomain.com:

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

You can specify multiple reporting destinations separated by commas, and you can use both mailto: and https: URIs. Many DMARC management platforms now include TLS-RPT parsing and visualization, which is much easier than reading the raw JSON reports manually.

MTA-STS Support Among Major Providers

MTA-STS vs DANE

DANE (DNS-based Authentication of Named Entities) is another protocol that enforces TLS on SMTP connections. It uses DNSSEC to publish TLS certificate information directly in DNS TLSA records. While DANE is technically stronger (it does not require a separate HTTPS server), it requires full DNSSEC deployment, which many domains do not have. MTA-STS was designed as a more practical alternative that works without DNSSEC, using HTTPS-based policy distribution instead.

In practice, most organizations that are not already running DNSSEC should deploy MTA-STS. If you already have full DNSSEC, DANE may be worth considering as a complement, but MTA-STS is the more widely adopted and supported standard among major mailbox providers.

Troubleshooting MTA-STS

Common issues you may encounter during or after deployment:

• Policy file not accessible: Ensure the mta-sts subdomain has a proper DNS A or CNAME record and that your web server is configured to serve the file at the exact path /.well-known/mta-sts.txt over HTTPS.
• Certificate mismatch: The TLS certificate on your MX hosts must match the hostnames listed in your MTA-STS policy. If your MX points to mail.yourdomain.com but the certificate is issued to yourdomain.com (without the mail subdomain), validation will fail.
• Stale cached policy: If you change your policy but forget to update the id in the DNS TXT record, remote servers will use the old cached version until max_age expires.
• Missing TLS 1.2+ support: MTA-STS requires TLS 1.2 or higher. If any of your MX hosts still only support TLS 1.0 or 1.1, upgrade them before enforcing.

Frequently Asked Questions