MTA-STS does not protect what you send

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: a glass tunnel enclosing one stream of particles, another travelling exposed

You may have published SPF, DKIM and DMARC. You have therefore settled the question of who is allowed to write in your name.

You have settled nothing at all about whether your messages travel encrypted, or whether someone can deprive you of that.

Two standards address exactly this. They are eight years old, jointly signed by Google, Microsoft, Comcast and Yahoo, and almost nobody publishes them.

What STARTTLS does not guarantee

SMTP transport encryption rests on an optional command. The receiving server announces that it can do TLS, the sender takes it up. If the announcement does not arrive, the message goes out in the clear.

It is a negotiation, so it can be tampered with. An intermediary that strips the announcement flips the exchange into plaintext without anyone noticing, and the message still arrives. Nothing fails, nothing alerts.

RFC 8461 names the problem in its abstract, in September 2018:

“SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.”

The direction of publication, which surprises everyone

Here is the point that derails half of all implementations, and it fits in one sentence.

MTA-STS does not protect what you send. It protects what is sent to you.

You publish a policy to tell servers worldwide: when you write to me, require TLS, verify my certificate, and refuse to deliver otherwise. The rule applies to them, on traffic inbound to you.

For your own sends to be protected, it is your recipient’s domain that must have published a policy, and your sending server that must know how to read it. Two conditions, and you control only one.

Many companies publish MTA-STS believing they are securing outbound email. They are securing their mailbox.

How it is published, concretely

Two objects, and not one more.

A DNS TXT record on _mta-sts.yourdomain.com, containing only a version and a policy identifier:

v=STSv1; id=20260908120000Z

And a text file served over HTTPS at a fixed address, https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, for which the RFC gives the example:

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

The identifier in DNS acts as a clock: when you change the file, you change the identifier, and senders know to re-read it. That is the entire update mechanism.

The three modes, and the only one that counts

Section 5 of the RFC defines exactly what a sender does according to the mode you declare.

“‘enforce’: In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.”

“‘testing’: In this mode, Sending MTAs that also implement the TLSRPT specification send a report indicating policy application failures […]; in any case, messages may be delivered as though there were no MTA-STS validation failure.”

“‘none’: In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy.”

Testing mode protects nothing. It observes. That is precisely its value: you publish it first, you read the reports, and you only move to enforce once you are certain none of your MX hosts fails validation.

Going straight to enforce with an expired certificate on a secondary MX means refusing your own inbound mail. The RFC does provide a safety net: “In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later.” The error is temporary, therefore fixable, but in the meantime the mail waits.

One last setting deserves attention. The policy lifetime is bounded: “max_age: Max lifetime of the policy (plaintext non-negative integer seconds, maximum value of 31557600).” One year at most, and the RFC recommends staying “in the range of weeks or greater”. Too short a value multiplies re-reads; too long a value makes a fix slow to propagate.

The report, without which you are blind

The companion standard, RFC 8460, published the same month, describes the return channel. Its abstract is explicit that it covers STARTTLS, DANE and MTA-STS alike:

“These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains.”

Publication is as light as MTA-STS: a TXT record on _smtp._tls.yourdomain.com naming a receiving address. You then receive daily JSON reports from the servers that write to you.

The report is what separates a serious deployment from a decorative DNS record. Without it, you publish a requirement without ever knowing how many connections fail it.

Proof that this is not theoretical

Microsoft publishes a dedicated code in its Exchange Online non-delivery report list:

“5.7.5 – Remote certificate failed MTA-STS validation.”

An operator of that size does not put a rejection code in its documentation for a standard it does not apply. When a recipient domain publishes an enforce policy and its certificate fails validation, Microsoft refuses delivery and says so with that code.

It is also a useful reminder: the TLS requirement already appears in the rules imposed on bulk senders. MTA-STS only adds what those rules do not cover: certificate verification, and a ban on falling back to plaintext.

What to do tomorrow morning

Query your own domain first: dig +short TXT _mta-sts.yourdomain.com and dig +short TXT _smtp._tls.yourdomain.com. Two empty answers is the most common case, including in companies that have taken care of DMARC.

Start with TLS-RPT alone. It changes nothing in sender behaviour, so it cannot break anything, and within days it gives you a measurement of what actually happens on your inbound connections.

Then publish MTA-STS in testing mode, with the exact list of your MX hosts. Check that each presents a certificate valid for the announced name, including the secondaries nobody watches.

Only move to enforce after a period with no failures in the reports. And put the renewal date of your MX certificates in the same calendar as your domain names: from that day on, an expired certificate no longer degrades encryption, it stops the mail.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.