← RFC Reference

MTA-STS — Mail Transfer Agent Strict Transport Security

Why This Exists

SMTP was designed in an era when email traveled in cleartext. STARTTLS (RFC 3207) added optional encryption, but it has a fatal flaw: it is opportunistic. A sending server asks "do you support TLS?" and an active network attacker can simply strip that response, forcing a plaintext downgrade. The sending server has no way to know the difference between "this server doesn't support TLS" and "an attacker removed the TLS offer."

MTA-STS solves this by letting domain owners publish a policy — over HTTPS, not DNS — that declares: "My mail servers always support TLS with valid certificates. If you can't establish a secure connection, refuse to deliver." Because the policy is fetched over HTTPS (which has its own certificate trust chain), an active attacker cannot forge or suppress it.

How It Works

MTA-STS requires two things from the receiving domain:

1. A DNS TXT record at _mta-sts.example.com that signals the policy exists and includes a version identifier for cache busting.
2. An HTTPS-served policy file at https://mta-sts.example.com/.well-known/mta-sts.txt that declares the actual policy.

Step 1: DNS Record

Publish a TXT record to advertise your MTA-STS policy:

The id field is an opaque string. Sending servers cache the policy and re-fetch it when the id changes. Use a timestamp or incrementing counter.

Step 2: Policy File

Host the policy at https://mta-sts.example.com/.well-known/mta-sts.txt. The HTTPS certificate must be valid for mta-sts.example.com.

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

Policy Fields

What the Sending Server Does

1. Looks up MX records for the recipient domain.
2. Checks for a cached MTA-STS policy, or fetches one if the DNS _mta-sts TXT record is new or changed.
3. Connects to an MX host and initiates STARTTLS.
4. Validates the MX server's TLS certificate against the mx patterns in the policy.
5. If mode is enforce and TLS fails or the certificate doesn't match: do not deliver. Queue the message and retry later.

Key Technical Details

Why HTTPS Instead of DNSSEC?

DNSSEC deployment remains limited. HTTPS leverages the widely-deployed Web PKI (Certificate Authority infrastructure). Any domain that can get a web certificate can use MTA-STS — no DNSSEC required. This is the key difference between MTA-STS and DANE (RFC 7672), which requires DNSSEC.

Trust on First Use (TOFU)

MTA-STS follows a TOFU model. The first time a sender encounters your policy, it must trust the DNS and HTTPS responses. After that, the cached policy protects against downgrades until max_age expires. An attacker would need to compromise both HTTPS and DNS simultaneously during the initial fetch — a significantly harder attack.

Testing Mode

Start with mode: testing. In this mode, sending servers deliver mail even if TLS validation fails, but generate TLS-RPT (RFC 8460) reports so you can identify problems before switching to enforce.

Deployment Example

A complete MTA-STS setup for example.com:

DNS Records

Policy File

# Served at https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

Once TLS-RPT reports confirm no issues, change mode to enforce and increase max_age to 604800 or higher.

Common Mistakes

• Certificate mismatch. The MX hostname in your policy must match the TLS certificate on that server. If your MX is mail.example.com but the cert is for *.mailprovider.com, enforcement will cause delivery failures.
• Forgetting to update the DNS id. Senders cache the policy keyed by the id. If you change the policy file but not the id, senders won't re-fetch it until max_age expires.
• Invalid HTTPS certificate on mta-sts.example.com. The policy hosting site must have a valid, publicly-trusted certificate. Self-signed or expired certificates will cause senders to ignore the policy.
• Jumping straight to enforce. Always start with testing and monitor TLS-RPT reports for at least two weeks. Misconfigured MX servers will silently lose mail in enforce mode.
• Short max_age in enforce mode. A short TTL means senders re-fetch frequently, widening the TOFU window. Use at least 604800 seconds (1 week) in production.
• Wildcard MX misuse. mx: * is not valid. Wildcards apply to the leftmost DNS label only: mx: *.example.com matches a.example.com but not a.b.example.com.

Deliverability Impact

MTA-STS does not directly improve inbox placement — it protects your recipients' mail from interception. However, it has indirect deliverability benefits:

• Builds domain trust. Google, Microsoft, and Yahoo all support MTA-STS. Publishing a policy signals that you take security seriously and run a well-maintained domain.
• Required for compliance. Industries handling sensitive data (finance, healthcare) increasingly require TLS enforcement for email. MTA-STS is the standard mechanism.
• Prevents silent downgrades. Without MTA-STS, an attacker on the network path can strip STARTTLS and intercept mail without either party knowing. This is a documented real-world attack.
• Pairs with TLS-RPT. RFC 8460 reporting gives you visibility into TLS failures across all senders — invaluable for diagnosing certificate or configuration issues before they affect delivery.

Related RFCs