# MTA-STS and TLS-RPT in 2026: Enforcing Strict Email Transit Encryption

_By Tayyab Mughal, Founder & AI Chief · 26 June 2026 · 1 min read_

> How to implement MTA Strict Transport Security (MTA-STS, RFC 8461) and TLS Reporting (TLS-RPT, RFC 8460) to prevent Man-in-the-Middle email tampering.

Standard SMTP opportunistic TLS (STARTTLS) is vulnerable to downgrade attacks. Here is how to configure MTA-STS policy files and TLS-RPT records for enterprise email transit security.

## The vulnerability of opportunistic STARTTLS

Traditional email transfer uses opportunistic TLS: if an attacker intercepts the connection (MITM) and strips the STARTTLS command, mail servers silently fall back to sending emails in plain unencrypted text.

MTA-STS (RFC 8461) closes this vulnerability by publishing an authoritative HTTPS policy requiring sending mail transfer agents (MTAs) to enforce TLS with valid certificates.

## 1. Publishing the MTA-STS Policy File

Host a plain-text file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

```text
version: STSv1
mode: enforce
mx: feedback-smtp.us-east-1.amazonses.com
mx: *.sadasend.com
max_age: 604800
```

## 2. Configuring DNS Records

Add the corresponding DNS TXT records to announce MTA-STS and receive automated TLS-RPT failure reports from Google and Microsoft.

```dns
; MTA-STS Announcement Record
_mta-sts.yourdomain.com.  IN TXT  "v=STSv1; id=2026082501;"

; TLS-RPT Aggregate Reporting Record
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@sadasend.com;"
```

---

_Tags: MTA-STS, TLS-RPT, Security, DNS_