MTA-STS and TLS-RPT: The Complete Email Transport Security Setup Guide for 2026

Email transport security has been quietly broken for decades. When two mail servers negotiate a connection, they typically use opportunistic STARTTLS, which means encryption is attempted but not required. An attacker sitting between the servers can simply strip the STARTTLS upgrade signal, forcing the connection to fall back to plaintext, and neither side will object.

MTA-STS fixes this by letting domain owners publish a strict policy that says: my mailbox accepts only authenticated, encrypted connections, and any sender that cannot meet that bar should defer or reject delivery instead of falling back to cleartext. TLS-RPT is the companion standard that gives you daily reports on whether senders are honoring that policy.

What Is MTA-STS and Why It Exists

MTA-STS is defined in RFC 8461 and was published in 2018 to address a long-standing weakness in SMTP security. The original SMTP specification did not include encryption. STARTTLS was added later as an optional upgrade, but because it was opportunistic, a network-level attacker could simply remove the STARTTLS advertisement from the server greeting and the sender would happily deliver mail in cleartext.

This downgrade attack has been observed in the wild against entire countries. Network operators and intelligence agencies have stripped STARTTLS at the AS level, making millions of messages traverse the public internet unencrypted. The TLS negotiation looked successful from a logging perspective because nothing failed; the encryption simply never happened.

MTA-STS solves this by moving the policy out-of-band. Sending servers fetch your policy over HTTPS, validate it against a trusted certificate authority, and remember the policy for the lifetime you specified. Even if an attacker strips STARTTLS on the SMTP connection itself, the sender already knows from the cached policy that your domain requires TLS, and will defer or reject the message rather than send it in plaintext.

How MTA-STS Works Under the Hood

MTA-STS has three moving parts that work together: a DNS TXT record, an HTTPS-hosted policy file, and the receiving MX servers themselves.

The DNS TXT Record

The first piece is a TXT record at _mta-sts.yourdomain.com that signals which version of your policy is currently active. The record looks like this:

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

The id field is a string you change every time you update your policy. Sending servers use it to detect that they need to refetch your policy file. A common convention is to use a timestamp, but any unique string works.

The Policy File

The second piece is a plain text file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The hostname must use a valid TLS certificate from a trusted CA, because the entire security model depends on senders being able to verify they are reading your real policy.

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

The mx lines list the hostnames of your MX records, including wildcard patterns if you use them. The max_age value is how long senders should cache the policy in seconds; 604800 seconds is one week, which RFC 8461 recommends as a minimum once you reach the enforce stage.

The Verification Flow

When a sender wants to deliver mail to your domain, it follows this sequence:

1. Look up your MX records via DNS
2. Check for an MTA-STS TXT record at _mta-sts.yourdomain.com
3. If the record exists and the cached id is stale, fetch the policy from the well-known URL
4. Validate the HTTPS certificate against a trusted CA
5. Cache the policy for max_age seconds
6. When connecting to your MX, require that the certificate matches one of the listed mx patterns and that TLS negotiation succeeds

If any step fails while the policy mode is enforce, the message is deferred and retried, or eventually bounced. In testing mode the failures are logged via TLS-RPT but the message is delivered anyway.

Policy Modes Explained

MTA-STS supports three modes that let you roll out enforcement gradually.

Mode: none

This is functionally equivalent to having no policy at all. It is used during decommissioning to tell senders to forget any cached enforce policy. Do not start a deployment in this mode.

Mode: testing

In testing mode, senders attempt to honor the policy but deliver the message regardless of whether TLS or certificate validation succeeds. Failures are logged and reported via TLS-RPT, giving you a window to identify legitimate senders that cannot meet your policy without losing mail.

Mode: enforce

In enforce mode, senders must successfully validate the policy. If TLS fails or the certificate does not match a listed MX, the message is deferred and ultimately bounced. This is the target state, but you should never deploy directly to enforce.

Step-by-Step Setup Walkthrough

Step 1: Audit Your MX Records

Before publishing anything, you need to know exactly which hostnames your inbound mail uses. Run a lookup against your domain and confirm every MX hostname has a valid TLS certificate that includes the hostname in its Subject Alternative Names. If any MX presents a self-signed or expired certificate, fix that first.

Step 2: Set Up the Policy Hostname

Create a subdomain mta-sts.yourdomain.com pointing to a web server. This can be a static file host, a CDN, or your existing webserver. The certificate at this hostname must be issued by a publicly trusted CA. A free Let's Encrypt certificate is fine.

Step 3: Publish the Policy File

Create the file at the path /.well-known/mta-sts.txt. Start with testing mode:

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

A short max_age of 86400 seconds (one day) is recommended during testing so policy updates propagate quickly.

Step 4: Publish the DNS TXT Record

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

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

Step 5: Publish the TLS-RPT Record

Add a separate TXT record at _smtp._tls.yourdomain.com to start receiving aggregate reports:

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

You will start receiving JSON reports within 24 to 48 hours, with one report per sender per day summarizing successful and failed TLS sessions.

Step 6: Monitor and Iterate

Watch your TLS-RPT reports for at least 30 days. Identify any persistent failures, fix the underlying issue (usually a certificate problem or an MX you forgot to list), and only then bump the mode to enforce and the max_age to 604800.

Reading TLS-RPT Reports

TLS-RPT reports arrive as gzipped JSON files attached to email messages. Each report covers a 24-hour window and contains one or more policies sections, each summarizing the success and failure counts for a specific policy type (MTA-STS or DANE).

A successful day looks like this:

{
  "organization-name": "Google LLC",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 1247,
      "total-failure-session-count": 0
    }
  }]
}

Failure reports include a failure-details array describing what went wrong. The most common failure types are certificate-expired, certificate-host-mismatch, starttls-not-supported, and validation-failure. Each one points to a specific fix.

MTA-STS vs DANE: Which Should You Use?

DANE (DNS-Based Authentication of Named Entities) is an alternative inbound TLS enforcement mechanism that uses DNSSEC-signed TLSA records instead of HTTPS. It is technically stronger because it removes the dependency on the public CA system, but it requires DNSSEC, which is operationally complex and incompatible with many DNS providers.

MTA-STS is far easier to deploy because it relies only on standard HTTPS and DNS infrastructure most domains already have. The two standards can coexist; senders that support both will typically prefer DANE when available and fall back to MTA-STS otherwise. For most senders, MTA-STS alone is the right starting point.

Common Issues and How to Fix Them

Certificate Hostname Mismatch

If your MX hostname is mail.example.com but the TLS certificate covers only example.com, validation will fail. Make sure the certificate Subject Alternative Names list every MX hostname you publish.

Policy File Not Found

Senders fetch the policy from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. A 404, redirect, or HTTP-only response will all break the policy. The path is case-sensitive and must be served over HTTPS with a valid public CA certificate.

Wildcard MX Patterns

If your provider uses wildcard MX hostnames like *.mail.example.com, you must include the wildcard in the policy file. The matching rule is the same as for TLS certificates: a single label match, with no recursion across dots.

Forgotten Policy ID Updates

This is the single most common operational mistake. After updating the policy file, increment the id field in the DNS TXT record so senders refetch instead of relying on cached data.

Which Senders Honor MTA-STS?

As of 2026, all major mailbox providers honor MTA-STS for outbound delivery. Google, Microsoft, Yahoo, and Apple have all confirmed policy enforcement. Most enterprise email security gateways including Proofpoint, Mimecast, and Barracuda also honor MTA-STS by default.

Smaller corporate MTAs and legacy systems are less consistent. TLS-RPT reports are the only reliable way to know who is actually validating your policy in production. After 30 days of testing mode you will have a clear picture, and the answer is almost always the senders that matter.

For a complete picture of how MTA-STS fits into the broader authentication stack, see the email authentication guide.

Frequently Asked Questions

← Back to Blog