MTA-STS: SMTP Strict Transport Security

📌 Introduction

Traditional SMTP transmits email in plaintext, which makes it vulnerable to downgrade attacks, DNS spoofing, and man-in-the-middle (MITM) attacks. To strengthen email security, major providers like Google, Microsoft, and Yahoo introduced MTA-STS (Mail Transfer Agent – Strict Transport Security).

The goal of MTA-STS is simple:

👉 Force all sending MTAs to use encrypted TLS with valid certificates, otherwise reject the delivery.

---

🔐 What Is MTA-STS?

MTA-STS is a security policy that allows domain owners to declare that inbound email must use:

1. TLS encryption
2. Valid certificates (no self-signed or expired certs)
3. No fallback to plaintext SMTP

If a secure TLS session cannot be established, the sending MTA will temporarily defer or reject the message instead of sending it insecurely.

---

🧩 Four Components of MTA-STS

1️⃣ DNS TXT record

Announces that your domain uses MTA-STS:

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

id is a version identifier and must be updated when policies change.

---

2️⃣ HTTPS Endpoint

Senders download your STS policy from:

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

Requirements:

• Must use HTTPS
• Must have a valid public CA certificate
• Must be publicly accessible

---

3️⃣ MTA-STS Policy File

Example:

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

Parameter reference:

Parameter	Meaning
version	Always STSv1
mode	testing / enforce / none
mx	Authorized MX hosts
max_age	Cache duration in seconds

---

4️⃣ Sender MTA Cache

Sending MTAs cache STS policies to avoid DNS interception.

---

🔄 How MTA-STS Works

1. Sender checks _mta-sts.example.com TXT
2. Downloads the HTTPS STS policy
3. Validates MX hostnames
4. Enforces TLS for delivery
5. Validates certificate chain
6. Caches the policy and completes delivery

If TLS negotiation or certificate validation fails, the sender will defer or reject delivery depending on the mode.

---

🆚 MTA-STS vs TLS-RPT vs DANE

Technology	Purpose	Pros	Cons
MTA-STS	Enforce TLS	No DNSSEC required, widely adopted	Needs HTTPS endpoint
TLS-RPT	TLS error reporting	Easy monitoring	Generates many reports
DANE	Certificate validation via DNSSEC	Extremely secure	DNSSEC is complex

Most enterprises deploy:
👉 MTA-STS (enforce) + TLS-RPT

---

🏗 How to Deploy MTA-STS

1️⃣ Add DNS TXT

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

2️⃣ Create HTTPS endpoint

File path:

/var/www/mta-sts/.well-known/mta-sts.txt

3️⃣ Create policy file

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

4️⃣ Ensure MX servers use valid public CA TLS certificates

• Proper CN/SAN
• TLS 1.2 / 1.3 support

5️⃣ (Recommended) Enable TLS-RPT

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

---

⚠ Common Mistakes

❌ Certificate CN/SAN mismatch

→ Email rejected

❌ Self-signed certificate

→ Delivery fails under enforce mode

❌ Forgetting to update id

→ Policy will not refresh

❌ Staying in “testing” mode

→ TLS is not enforced

---

🎯 Conclusion

MTA-STS is an essential security layer for any modern email system. It is easy to deploy, requires no DNSSEC, and is supported by all major providers. If you manage Postfix, Dovecot, or any enterprise mail infrastructure, enabling MTA-STS + TLS-RPT greatly enhances trust, security, and deliverability.