MTA-STS and TLS-RPT — Securing Email Transport

Why STARTTLS alone is not enough

Most email servers today support transport encryption via STARTTLS. The problem is that STARTTLS is opportunistic — the sending server attempts an encrypted connection, but if the other side doesn't respond or the connection fails, it sends the email unencrypted. An attacker controlling the network traffic between servers can actively suppress encryption (downgrade attack) or redirect traffic to a rogue server (MX spoofing).

MTA-STS and TLS-RPT address these weaknesses. MTA-STS allows a domain to require encrypted connections and verify the identity of the receiving server. TLS-RPT provides feedback — reports on whether encrypted delivery is succeeding or where it's failing.

What is MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard defined in RFC 8461. It allows a domain to declare that its mail servers support TLS and that sending servers should refuse delivery if an encrypted connection cannot be established.

Unlike opportunistic STARTTLS, where TLS failure leads to unencrypted delivery, MTA-STS says: "Encrypt or don't deliver."

How MTA-STS works

1. The sending server wants to deliver an email to example.com.
2. It queries DNS for the _mta-sts.example.com record — if it exists, the domain supports MTA-STS.
3. It fetches the policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
4. The policy lists the authorized MX servers and the enforcement mode.
5. The server establishes a TLS connection and verifies the certificate matches the declared MX server.
6. If verification fails and the policy is in enforce mode, the email is not delivered.

Two components of MTA-STS

MTA-STS requires setting up two things:

1. DNS TXT record

A TXT record at the _mta-sts subdomain signals MTA-STS support and contains the policy version identifier:

_mta-sts.example.com IN TXT "v=STSv1; id=20260325T100000;"

The id value can be any alphanumeric string (max 32 characters). Using a timestamp in YYYYMMDDTHHmmss format is recommended.

2. HTTPS policy file

A text file served at https://mta-sts.example.com/.well-known/mta-sts.txt:

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

The file must be served over HTTPS with a valid certificate. You need to point the mta-sts.example.com subdomain to a web server (or static site hosting) that serves this file.

MTA-STS modes

Always start with testing mode. Switch to enforce only after reviewing TLS-RPT reports that confirm all legitimate servers connect over TLS without issues.

What is TLS-RPT

TLS-RPT (SMTP TLS Reporting) is a standard defined in RFC 8460. It serves as a reporting mechanism for email transport security policies (both MTA-STS and DANE) — sending servers deliver reports to the domain owner about TLS connection results when delivering email.

The concept is similar to DMARC reports, but instead of email authentication, it tracks transport encryption.

DNS record for TLS-RPT

TLS-RPT is activated with a single TXT record at the _smtp._tls subdomain:

_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=mailto:example.com@rua.spfmonitor.com"

You can send reports to your own email address or to a service that processes them automatically. SPF Monitor parses, visualizes, and alerts you to issues — no need to manually parse JSON files.

To receive reports at multiple addresses, separate them with a comma:

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

What TLS-RPT reports contain

Reports are sent in JSON format, typically once per day. They include:

• Domain and period — which domain and time period the report covers
• Successful connections — count of successfully established TLS connections
• Failures — type and reason for failure (expired certificate, invalid hostname, unsupported TLS version, MTA-STS policy violation)
• Source and destination servers — IP addresses and hostnames of the servers involved

Deploying MTA-STS and TLS-RPT step by step

1. Verify your current configuration

Check that your MX records point to servers with valid TLS certificates. Analyze your domain and verify that SPF, DKIM, and DMARC are working correctly — MTA-STS is an additional security layer that complements authentication.

2. Enable TLS-RPT

Start with TLS-RPT reporting before enabling MTA-STS. Add a DNS TXT record:

_smtp._tls.example.com IN TXT "v=TLSRPTv1; rua=mailto:example.com@rua.spfmonitor.com"

You'll start receiving reports from servers that support TLS-RPT (Google, Microsoft, and other major providers). Report data will show whether TLS connections are being established successfully.

3. Set up MTA-STS policy in testing mode

Create the mta-sts.example.com subdomain and point it to a web server with HTTPS. Serve the policy at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

In testing mode, use a shorter max_age (e.g., 86,400 seconds = 1 day) so you can respond quickly to issues.

4. Add the MTA-STS DNS record

_mta-sts.example.com IN TXT "v=STSv1; id=20260325T100000;"

5. Monitor TLS-RPT reports

Wait at least 2–4 weeks and monitor incoming TLS-RPT reports. Look for:

• TLS handshake failures
• Certificate errors (expired, incorrect hostname)
• Servers unable to establish encrypted connections

Fix any issues before switching to enforce.

6. Switch to enforce

Once reports confirm smooth TLS connections, update the policy:

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

Increase max_age to 604,800 seconds (7 days) or more. Don't forget to update the id in the DNS TXT record.

Where to host the MTA-STS policy

The MTA-STS policy must be served over HTTPS on the mta-sts subdomain. You have several options:

• Your own web server — if you already run a website on the domain, add the subdomain and file
• GitHub Pages — free static site hosting with automatic HTTPS (there are MTA-STS templates available)
• Cloudflare Workers — a serverless function that returns the policy content
• Cloud storage (S3, Cloud Storage) — with a custom domain and HTTPS

Key requirement: the mta-sts.example.com subdomain must have a valid TLS certificate and the file should be served with Content-Type: text/plain. Verify the HTTPS configuration of your subdomain.

MTA-STS vs. DANE

There is an alternative approach to email transport security: DANE (DNS-based Authentication of Named Entities, RFC 7672). DANE uses DNSSEC to publish TLS certificate information directly in DNS records (TLSA records).

In practice, MTA-STS is deployed far more frequently because it doesn't require DNSSEC — a technology that many domains still haven't activated. Google and Microsoft fully support MTA-STS on both the sending and receiving side.

Who supports MTA-STS

On the receiving side (your domain)

You can deploy MTA-STS on any domain — all you need is a DNS record and an HTTPS file. It works regardless of which mail server you use.

On the sending side (who respects your policy)

The following senders respect MTA-STS policies:

• Google (Gmail, Google Workspace) — full support
• Microsoft (Outlook.com, Exchange Online) — full support since 2022
• Yahoo — supported (extent not fully documented)
• Postfix 3.4+ — supported via external policy daemon (postfix-mta-sts-resolver) using the socketmap interface

If the sending server doesn't support MTA-STS, it simply ignores your policy and delivers the email the standard way. MTA-STS deployment cannot cause lost emails from unsupported servers — provided your MX servers support TLS.

Practical questions about MTA-STS deployment

Can MTA-STS cause email delivery failures?

In testing mode, no — emails are delivered even on TLS failure, only a report is generated. In enforce mode, yes — if the sending server can't establish a verified TLS connection with your MX server, the email won't be delivered. That's why gradual deployment with TLS-RPT monitoring is essential.

Do I need MTA-STS if I have DMARC?

Yes. DMARC handles sender authentication (who sent the email). MTA-STS handles transport encryption (how the email travels between servers). They are complementary security layers — DMARC protects against identity spoofing, MTA-STS protects message content from eavesdropping.

How to update the MTA-STS policy?

1. Edit the file at https://mta-sts.example.com/.well-known/mta-sts.txt.
2. Update the id value in the _mta-sts.example.com DNS TXT record to a new unique value.

Sending servers cache the policy for the duration of max_age. Changing the id in DNS signals them to fetch the new version.

How MTA-STS fits into your email security stack

MTA-STS and TLS-RPT complement the SPF, DKIM, and DMARC trio with a transport security layer. While authentication protocols verify who sent the email, MTA-STS ensures that message content can't be read or modified in transit.

Check your domain security to see which protection layers are in place and where gaps remain.