MTA-STS and TLS-RPT: securing email transport

SPF, DKIM and DMARC protect an email’s identity.

MTA-STS and TLS-RPT protect its transport path instead.

These two mechanisms help a domain tell other servers: “when you deliver mail to me, use TLS properly, and let me know if something fails”.

The problem: SMTP often uses TLS opportunistically

When one mail server delivers a message to another, it uses SMTP.

In many cases, TLS is negotiated with STARTTLS. That is useful, but historically opportunistic: if TLS is not offered, or the connection is downgraded, some servers may still attempt a less secure delivery.

An attacker on the path may try to trigger that kind of downgrade.

They may also try to manipulate DNS resolution or the route to the recipient domain’s MX servers.

MTA-STS addresses this risk:

If my domain announces a strict TLS policy, compatible servers must refuse a delivery that does not meet it.

What is MTA-STS for?

MTA-STS stands for Mail Transfer Agent Strict Transport Security.

It lets a domain publish a policy stating:

that its MX servers accept TLS;
which MX servers are authorised;
which mode to apply;
how long the policy can be cached.

MTA-STS announces a TLS policy with a DNS TXT record and an HTTPS file

In practice, a compatible sender checks the recipient domain’s MTA-STS policy before delivering.

If the policy is strict and the MX does not present a valid TLS certificate, delivery must be refused rather than downgraded.

MTA-STS therefore prevents two classic scenarios:

TLS downgrade, where an encrypted connection becomes unencrypted;
diversion to a wrong MX that does not match the published policy.

How an MTA-STS policy is published

MTA-STS relies on two elements.

First, a DNS TXT record:

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

The id field is a version identifier. When the policy changes, you also change this identifier so that compatible senders reload it.

Then, a file available over HTTPS:

https://mta-sts.example.com/.well-known/mta-sts.txt

Example content:

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

The important fields are:

version: the policy version;
mode: the expected behaviour;
mx: the authorised MX servers;
max_age: how long the policy may be cached.

MTA-STS modes

MTA-STS has three main modes.

none publishes a policy without requiring strict enforcement. It is mostly used to prepare or cleanly disable.

testing lets you receive reports without abruptly blocking messages.

enforce asks compatible senders to refuse delivery if valid TLS is not available or if the MX does not match the policy.

Gradual MTA-STS deployment with the none, testing and enforce modes

Good practice is to start with testing, a short max_age and TLS-RPT enabled.

Once reports are clean and MX servers validated, gradually increase max_age, then switch to enforce.

What is TLS-RPT for?

TLS-RPT stands for SMTP TLS Reporting.

It lets a domain receive reports about problems senders encounter when trying to deliver email over TLS.

Without TLS-RPT, an MTA-STS policy can fail silently: a partner can no longer deliver, but you do not necessarily see the cause clearly.

TLS-RPT provides that visibility.

TLS-RPT centralises reports sent by Gmail, Microsoft and Yahoo

It is published with a TXT record:

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

Reports can also be sent to an HTTPS URL, depending on implementations.

They contain aggregated information: domain concerned, policy applied, number of sessions, failure types and the period observed.

What the reports can reveal

TLS-RPT is particularly useful during infrastructure changes.

It can reveal:

an expired certificate;
a certificate that does not cover the MX name;
an MX missing from the MTA-STS policy;
a certificate chain problem;
a TLS incompatibility;
a DNS error;
a partner still trying to deliver to an old server;
a mail gateway that does not present the right certificate.

These reports do not replace SMTP logs, but they give an external view.

That is valuable, because what works from your server does not always work from Gmail, Microsoft, Yahoo or other senders.

MTA-STS, TLS-RPT and DNSSEC

MTA-STS does not replace DNSSEC or SMTP DANE.

It works differently.

SMTP DANE relies on DNSSEC to publish verifiable TLS information in DNS.

MTA-STS relies on a DNS TXT record, then on a policy fetched over HTTPS.

Both approaches aim to secure SMTP transport, but with different dependencies. Our article on DNSSEC, SMTP DANE and MTA-STS in Exchange Online shows how Microsoft is adopting them.

In many environments, MTA-STS is easier to deploy than DANE, because it does not necessarily require DNSSEC across the whole DNS chain.

On the other hand, it requires properly maintaining:

the mta-sts subdomain;
that subdomain’s HTTPS certificate;
the list of authorised MX servers;
the policy mode;
the max_age;
receiving and analysing TLS-RPT reports.

Common mistakes

The most common MTA-STS mistakes are fairly predictable.

They often include:

an enforce policy published too early;
a max_age that is too long from the first deployment;
a real MX missing from the policy;
a misunderstood wildcard mx;
an invalid TLS certificate on an MX;
an mta-sts.txt file not reachable over HTTPS;
a _mta-sts TXT record whose id is not updated after a change;
an unmonitored TLS-RPT address.

These errors can cause queued mail, delays or rejections at compatible senders.

Email transport security should therefore be prepared like a production change.

Deployment method

For a small business or an organisation with several flows, the safest method is gradual.

Recommended steps:

inventory the domain’s real MX servers;
check the TLS certificates those MX servers present;
publish TLS-RPT;
publish MTA-STS in testing;
monitor reports for a few days;
fix the MX servers, certificates or gateways reported;
gradually increase max_age;
switch to enforce only when reports are clean;
document the policy and dependencies.

This approach keeps a security improvement from turning into a mail incident.

Conclusion

MTA-STS and TLS-RPT add a layer of trust to email transport.

MTA-STS lets a domain require TLS and declare its authorised MX servers.

TLS-RPT lets it receive reports when senders run into secure delivery problems.

Together, they help detect certificate errors, wrong MX servers, TLS downgrades and abnormal delivery paths.

They do not replace SPF, DKIM, DMARC, DNSSEC or DANE. They complement the email architecture on another layer: the SMTP path between servers.

To follow these reports over time alongside your DMARC reports, see Dharmail’s DMARC monitoring and supervision service (page in French).

Useful sources: RFC 8461 - SMTP MTA Strict Transport Security and RFC 8460 - SMTP TLS Reporting.

MTA-STS & TLS-RPT: securing email transport