MTA-STS and TLS-RPT: Making Email Encryption in Transit Something You Can Enforce

The problem: opportunistic encryption

When one mail server delivers to another, it usually offers to upgrade the connection with STARTTLS (RFC 3207). If the receiving server supports it, the session is encrypted. But the default behavior is to fall back to plain text if the upgrade fails, and many senders do not verify the certificate. An attacker in the network path can strip the offer or present a fake certificate. The mail still arrives, and nobody notices that it was readable on the way.

What MTA-STS does

Mail Transfer Agent Strict Transport Security (MTA-STS) is defined in RFC 8461. It lets a receiving domain publish a policy that tells senders: deliver only to these mail servers, use TLS, and check the certificate. It is the SMTP counterpart of HTTP Strict Transport Security. Senders that support it cache the policy and refuse to deliver on a downgraded connection, instead of falling back.

It protects mail sent to you. It does not control how you send mail to others; for that, your own mail platform's outbound settings apply.

The two pieces you publish

• A DNS TXT record at _mta-sts.yourdomain with a version and an id, for example v=STSv1; id=20261109. Change the id whenever the policy changes, so senders fetch the new one.
• A policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt. It has plain text lines: version: STSv1, mode, one or more mx lines naming your mail servers, and max_age in seconds.

The policy host needs a certificate that is valid for the mta-sts name and issued by a public certificate authority. Senders fetch the file over HTTPS, so if the certificate expires, the policy cannot be refreshed. Put this certificate under the same renewal automation as your other web certificates.

Modes and max_age

• testing: senders still deliver even if TLS validation fails, and can report the problem. Use this first.
• enforce: senders must not deliver if the connection cannot use TLS with a valid certificate for one of the listed mx names. Failed attempts are deferred and retried.
• none: the policy is effectively switched off, which is how you retire it cleanly.
• max_age: how long a sender may cache the policy. A longer value protects you better against an attacker who blocks the policy fetch, but also delays changes. Start short while testing and lengthen it once things are stable.

TLS-RPT: the reporting half

SMTP TLS Reporting (TLS-RPT) is defined in RFC 8460. You publish a TXT record at _smtp._tls.yourdomain, for example v=TLSRPTv1; rua=mailto:reports@yourdomain. Large senders then send you a daily JSON report listing how many TLS sessions succeeded and failed, and why: expired certificate, name mismatch, no STARTTLS offered and so on. Reports can be sent by email or posted to an HTTPS endpoint. Publish it before the MTA-STS policy so you have data from the start.

A safe rollout

• List your inbound mail servers and make sure each has a certificate valid for its MX name, with a complete chain and automated renewal.
• Publish TLS-RPT and read the reports for a couple of weeks to see the baseline.
• Publish MTA-STS in testing mode, with a short max_age.
• Read the reports. Fix mismatched names, expired certificates and any relay that sits in front of your mail servers, such as a filtering service, which must also offer valid TLS.
• Switch to enforce and raise max_age. Keep reading the reports; a certificate that expires later will show up there.
• Add this to your change process: new mail server or provider means a policy update with a new id before cutover.

MTA-STS versus DANE

DANE for SMTP (RFC 7672) publishes certificate information in DNS and depends on DNSSEC. MTA-STS publishes a policy on the web and depends on certificate authorities. DANE is stronger against some attacks but only works if your domain and mail hosts are signed with DNSSEC and the sender checks it. Many organizations choose MTA-STS because it is simpler to deploy, and some publish both.

What it does not do

• It does not encrypt mail end to end. The message is still readable by the receiving mail systems.
• It only protects senders that implement it. Large providers do, but not every sender.
• It does not replace SPF, DKIM or DMARC, which address who the sender is, not whether the connection is encrypted.

If you want MTA-STS and TLS-RPT set up and watched as part of an email security project, ask about our Email Security and Archiving service. This article is general information; test any DNS or certificate change before relying on it.

Sources

• RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460, SMTP TLS Reporting
• RFC 7672, SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) TLSA
• RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 6125, Representation and Verification of Domain-Based Application Service Identity in PKIX

This article is general information, not legal, contracting or technical advice for your environment. Test DNS, certificate and mail-flow changes with your own administrator before moving to enforce. Last reviewed November 9, 2026.

Next article

Next · SecurityContent Security Policy and Subresource Integrity for Payment Pages: What PCI DSS 6.4.3 Asks ForSkimming attacks hide in the scripts a checkout page loads. PCI DSS 4.0.1 now asks merchants to know every script on a payment page and to keep each one under control. Two browser features, CSP and SRI, do a good part of that work. Here is what they do and where they stop.8 min read

Related reading

• SecurityReading DMARC Aggregate Reports in Practice: XML Fields, Alignment vs Pass, Unknown Senders, Forwarding and ARC8 min
• SecurityBIMI, VMC and CMC Explained: A Logo in the Inbox, What It Needs and What It Does Not Prove7 min