Skip to content
Back to Blog
DMARC.WS Team··8 min read

MTA-STS: Enforcing TLS Encryption for Email in Transit

MTA-STSTLSEmail SecurityGuide

The Problem with Opportunistic TLS

Most email servers today support TLS encryption. When Server A connects to Server B to deliver a message, they negotiate a TLS connection. If it works, the message travels encrypted. If it fails, they fall back to sending the message in plain text.

This is called opportunistic TLS — encryption is attempted but not required. It protects against passive eavesdroppers but is vulnerable to active attackers who can:

  1. Strip the STARTTLS offer: An attacker performing a man-in-the-middle attack modifies the server's response to hide the fact that it supports TLS. The sending server sees no TLS support and sends the email unencrypted.

  2. Present a fraudulent certificate: The attacker intercepts the connection and presents their own certificate. Without strict validation, the sending server accepts it and the attacker can read the message.

  3. Downgrade the connection: The attacker causes the TLS handshake to fail, forcing a fallback to plain text.

These are real attack vectors used by nation-state actors and sophisticated attackers to intercept email in transit.

What Is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets domain owners declare that their mail servers support TLS and that senders should refuse to deliver email over unencrypted connections.

It's conceptually similar to HSTS for websites: once a sender knows your domain requires TLS, it won't fall back to plain text, even if an attacker tries to force a downgrade.

How MTA-STS Works

MTA-STS uses two components:

1. DNS Record

A TXT record at _mta-sts.{domain} signals that the domain has an MTA-STS policy:

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

The id field is a version string that senders use to detect policy changes. Update it whenever you modify your policy file.

2. Policy File

An HTTPS-served file at https://mta-sts.{domain}/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
max_age: 604800
Field Purpose
version Must be STSv1
mode Policy mode: enforce, testing, or none
mx Allowed MX hostnames (one per line, wildcards allowed)
max_age How long senders should cache the policy (in seconds)

Policy Modes

testing

Senders attempt TLS but still deliver via plain text if it fails. Failed connections are reported via TLS-RPT. Use this mode first to identify issues without risking email delivery.

enforce

Senders require TLS with a valid certificate. If TLS fails, the message is not delivered. This is the target mode for full protection.

none

Effectively disables MTA-STS. Use this to gracefully remove MTA-STS if needed.

Setting Up MTA-STS

Step 1: Verify Your TLS Configuration

Before deploying MTA-STS, ensure your mail servers have:

  • Valid TLS certificates from a trusted CA
  • Certificates that match your MX hostnames
  • Automated certificate renewal
  • TLS 1.2 or higher support

Step 2: Create the Policy File

Create the file at the exact path /.well-known/mta-sts.txt on the host mta-sts.{yourdomain}:

version: STSv1
mode: testing
mx: mail.example.com
mx: mail2.example.com
max_age: 86400

Start with mode: testing and a short max_age (86400 = 1 day) so you can iterate quickly.

Hosting requirements:

  • Must be served over HTTPS with a valid certificate
  • The mta-sts.example.com subdomain needs an A record and TLS certificate
  • Returns content type text/plain

Common hosting options:

  • A simple static file on your web server
  • GitHub Pages or Cloudflare Pages
  • A dedicated mta-sts subdomain with a minimal web server

Step 3: Publish the DNS Record

Host: _mta-sts
Type: TXT
Value: v=STSv1; id=20260301

Step 4: Set Up TLS-RPT

Deploy TLS-RPT alongside MTA-STS for visibility:

Host: _smtp._tls
Type: TXT
Value: v=TLSRPTv1; rua=mailto:tls-reports@example.com

Step 5: Monitor in Testing Mode

Wait 2–4 weeks and review TLS reports for:

  • Successful TLS connections (good — these will continue working in enforce mode)
  • Failed TLS connections (investigate — these will bounce in enforce mode)
  • Policy fetch errors (fix — senders can't retrieve your policy)

Step 6: Switch to Enforce Mode

Once you're confident:

  1. Update the policy file: change mode: testing to mode: enforce
  2. Increase max_age to a longer duration (604800 = 1 week is common)
  3. Update the DNS record's id value to signal the policy change

The MX Matching Rule

The mx entries in your policy must match the hostnames your MX DNS records point to. This is how senders verify they're connecting to the right server.

; DNS
example.com.    IN MX 10 mail.example.com.
example.com.    IN MX 20 backup.example.com.

; MTA-STS policy
mx: mail.example.com
mx: backup.example.com

You can use wildcards: mx: *.example.com matches any subdomain. But be precise — overly broad wildcards reduce security.

Important: The certificate on each MX server must match the hostname. If your MX points to mail.example.com, the server at that address must present a certificate valid for mail.example.com.

MTA-STS vs DANE

Both MTA-STS and DANE (DNS-Based Authentication of Named Entities) solve the same problem — enforcing TLS for email. But they work differently:

Aspect MTA-STS DANE
Requires DNSSEC No Yes
Discovery method DNS + HTTPS DNS (TLSA records)
Certificate validation WebPKI (standard CAs) DNSSEC-validated TLSA
Adoption Growing Slower (DNSSEC barrier)
Deployment difficulty Moderate Higher (needs DNSSEC)

Most organizations choose MTA-STS because it doesn't require DNSSEC, which many domain registrars and DNS providers don't support well.

Common Issues

Policy File Unreachable

Symptom: TLS reports show sts-policy-fetch-error Fix: Verify https://mta-sts.example.com/.well-known/mta-sts.txt is accessible, returns 200, and has a valid HTTPS certificate.

Certificate Mismatch

Symptom: TLS reports show certificate-host-mismatch Fix: Ensure your MX server's certificate SANs include the exact hostname in your MX record and MTA-STS policy.

Stale Cache After MX Change

Symptom: Delivery issues after changing MX records Fix: When changing MX servers, update the MTA-STS policy first, bump the id in DNS, and wait for the old max_age to expire before decommissioning old servers.

Summary

MTA-STS closes the gap left by opportunistic TLS by telling senders "you must use encryption, and the certificate must be valid." Combined with TLS-RPT for monitoring, it ensures your email connections are genuinely encrypted and not just pretending to be.

The setup requires a DNS record, a hosted policy file, and valid TLS certificates — all straightforward for organizations that already manage their email infrastructure. Start in testing mode, monitor TLS reports, and switch to enforce once you're confident.