MTA-STS Explained: How to Enforce TLS for Email in Transit

When you send an email, you probably assume it is encrypted in transit. In reality, SMTP — the protocol that delivers email between servers — was designed in 1982 with no encryption at all. While STARTTLS was added later to opportunistically upgrade connections to TLS, it is trivially vulnerable to downgrade attacks. MTA-STS (Mail Transfer Agent Strict Transport Security) solves this by letting domain owners declare that their mail servers require TLS and that sending servers should refuse to deliver over an unencrypted connection.

The Problem: SMTP Is Plaintext by Default

SMTP connections between mail servers start unencrypted on port 25. STARTTLS is an extension that allows a server to advertise TLS support, enabling the sending server to upgrade the connection to encrypted. However, this upgrade is opportunistic: if a man-in-the-middle attacker strips the STARTTLS advertisement from the server's response (a technique called a STARTTLS stripping attack), the sending server will fall back to plaintext without any warning.

This is not a theoretical risk. Nation-state actors and network-level adversaries have been documented performing STARTTLS stripping at scale, intercepting email traffic between major providers. Without a mechanism to tell senders “my server always supports TLS, do not fall back to plaintext,” there is no way to prevent these downgrade attacks.

How MTA-STS Works

MTA-STS (defined in RFC 8461) uses two components: a DNS TXT record and an HTTPS-hosted policy file. Together, they tell sending mail servers that your domain requires TLS for inbound email.

Step 1: The DNS record. You publish a TXT record at _mta-sts.yourdomain.com with the value v=STSv1; id=20260313001;. The id field is a version string that you change whenever you update your policy. Sending servers cache the policy and re-fetch it when they see a new id value.

Step 2: The policy file. You host a plain text file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This file must be served over HTTPS with a valid certificate. The policy file contains the version, the mode, the maximum age (in seconds) that senders should cache the policy, and a list of MX hostnames that are authorized to receive mail.

A typical policy file looks like this:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

When a sending server wants to deliver email to your domain, it looks up the MTA-STS DNS record, fetches the policy file over HTTPS, and then validates that the receiving MX server's TLS certificate matches the hostnames listed in the policy. If the connection cannot be established with valid TLS, the sending server queues or bounces the message instead of delivering it in plaintext.

Policy Modes: Testing vs Enforce

MTA-STS supports two operational modes. Testing mode (mode: testing) tells sending servers to attempt TLS and report failures, but still deliver the email even if TLS fails. This is the recommended starting point because it lets you identify issues without risking email loss.

Enforce mode (mode: enforce) instructs sending servers to reject delivery if a valid TLS connection cannot be established. Only switch to enforce mode after running in testing mode long enough to confirm that all sending servers can connect successfully over TLS. The max_age value determines how long senders cache your policy; a typical value is 604800 seconds (one week) for enforce mode, or 86400 (one day) during testing.

Setting Up MTA-STS Step by Step

1. Ensure your MX servers support TLS with valid certificates. The certificates must match the hostnames you will list in the policy file. Use our SSL Checker to verify your mail server certificates.

2. Create the policy file and host it at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. You need a subdomain mta-sts with a valid TLS certificate. Many people host this on a static site platform like Cloudflare Pages, Vercel, or GitHub Pages.

3. Publish the DNS TXT record at _mta-sts.yourdomain.com. Verify it with our TXT Lookup or DNS Lookup tool.

4. Start in testing mode. Set mode: testing and monitor TLS-RPT reports (see below) for at least two weeks before switching to enforce.

5. Switch to enforce mode once you are confident that TLS works reliably for all inbound email. Update the policy file, change the id in the DNS record, and set max_age to one week or more.

TLS-RPT: Monitoring TLS Failures

TLS-RPT (TLS Reporting, defined in RFC 8460) works alongside MTA-STS to give you visibility into TLS connection failures. You publish a DNS TXT record at _smtp._tls.yourdomain.com with a value like v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com. Sending servers that support TLS-RPT will send you daily JSON reports detailing successful and failed TLS connections, including the failure reason (certificate mismatch, expired cert, STARTTLS stripping, etc.).

These reports are essential during the testing phase and remain valuable in enforce mode for ongoing monitoring. They alert you to certificate issues, misconfigured MX servers, or potential man-in-the-middle attacks.

MTA-STS vs DANE

DANE (DNS-based Authentication of Named Entities) is an alternative approach to enforcing TLS for email. Instead of an HTTPS-hosted policy file, DANE publishes TLS certificate information directly in DNS using TLSA records, secured by DNSSEC. DANE is technically superior because it does not require a separate HTTPS endpoint, but it depends on DNSSEC, which is still not universally deployed. Many major email providers (including Gmail) support MTA-STS but not DANE.

In practice, MTA-STS is easier to deploy and has broader support among large mailbox providers. If your domain already uses DNSSEC, consider implementing both DANE and MTA-STS for maximum coverage. If DNSSEC is not an option, MTA-STS is your best path to enforced TLS.

MTA-STS and Your Security Stack

MTA-STS protects email in transit, complementing SPF, DKIM, and DMARC which protect email authenticity. Together, they form a comprehensive email security posture. Run a Domain Health Check to see how all your email security records work together.

For more on email authentication protocols, read our SPF, DKIM & DMARC explained guide. For details on TLS certificates and how they work, see our SSL/TLS Certificates Explained article.