aegis · May 9, 2026 · 7 min read

MTA-STS: Secure Email Channels Against Downgrade Attacks

MTA-STS enforces strict TLS on your SMTP and blocks downgrade attacks that expose email content to attackers. Configuration in 1 day, continuous monitoring.

CAI Technology · Last reviewed: 5/9/2026

MTA-STS: Secure Email Channels Against Downgrade Attacks

In Short

MTA-STS (Mail Transport Agent Strict Transport Security, RFC 8461) is a mechanism by which a domain publishes an HTTPS policy declaring which MX servers are legitimate and that TLS is mandatory for any incoming SMTP connection. Combined with TLS-RPT (RFC 8460) for violation reporting, it offers complete visibility into downgrade attacks.

The reality in 2026 (Google Transparency Report): approximately 30% of B2B emails in the EU are sent/received without TLS — they are in cleartext in transit.

For organizations under NIS2 Art.21.2.h (mandatory email encryption) or those signing NDAs assuming secure email, the lack of MTA-STS is a documentable gap in the event of an audit.

The SMTP Downgrade Attack — How It Works

With or without STARTTLS, basic SMTP is opportunistic encryption. An attacker in the SMTP path (BGP path, compromised ISP, on-path attacker in a datacenter) can:

Intercept the SMTP connection from mail.partner.com to mail.company.com
During handshake, the company.com server announces the STARTTLS capability
The attacker deletes the STARTTLS line from the server response
The partner server believes mail.company.com does not support TLS → falls back to plain SMTP
Email content (subject, body, attachments) circulates in cleartext through the attacker’s network

Result: the attacker reads email conversations in real time. For a state-level attacker or aggressive competitor, this is a direct path to IP, contracts, M&A discussions, and trade secrets.

How MTA-STS Solves This

MTA-STS states: “If my MX does not support strict TLS with a valid certificate, do not send the email at all. Better to delay it than send it in cleartext.”

The receiver (Gmail, Outlook365, partner MTA) performs the following flow:

Receives outbound email destined for company.com
Looks up _mta-sts.company.com TXT record → finds v=STSv1; id=...
Requests https://mta-sts.company.com/.well-known/mta-sts.txt over HTTPS
Reads policy: mode: enforce, mx: mail.company.com, max_age: 86400
Forces TLS on the connection to mail.company.com
If the MX cert is invalid or STARTTLS fails → email rejected, reported to TLS-RPT

Step-by-Step Implementation

Step 1 — Verify Your MX Supports TLS

openssl s_client -starttls smtp -crlf -connect mail.company.com:25

Ensure the MX TLS certificate is:

Valid (signed by Let’s Encrypt or another trusted CA)
Cert name matches the MX (Common Name or SAN)
Not expired

Step 2 — Publish TXT Record

_mta-sts.company.com.   IN  TXT  "v=STSv1; id=20260509120000"

id is a timestamp — modify it when updating the policy (forces caches to refresh).

Step 3 — Publish HTTPS Policy

Subdomain mta-sts.company.com with valid SSL (Let’s Encrypt OK). Policy file at /.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.company.com
mx: backup.company.com
max_age: 86400

testing mode for the first 30 days — receivers report violations but do not block email. After 30 days without false positives → switch to mode: enforce.

Step 4 — Add TLS-RPT for Reporting

_smtp._tls.company.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@company.com"

Major receivers (Gmail, Outlook365) send daily JSON reports to the specified address with detected TLS errors. Use a parser (e.g., parsedmarc extended for TLS-RPT) for visualization.

Step 5 — Monitor + Ramp to Enforce

After 30 days of mode=testing without false-positive violations → switch to mode: enforce. Document the procedure in your internal runbook.

Common Confusions

“I have DKIM and DMARC, that’s enough.” — No. DKIM and DMARC verify authenticity (who sent the email). MTA-STS secures the channel (how it traveled). These are different layers, both necessary.

“The partner receiver must support MTA-STS, otherwise it doesn’t work.” — Partially true. Gmail, Outlook365, Yahoo Mail — all support MTA-STS since 2019. Small receivers (partner SMB internal mail) might not — in that case, MTA-STS only protects receivers that support it (the majority). Still better than nothing.

“Opportunistic TLS is enough.” — No. Opportunistic = attacker can cause downgrade. Strict = they cannot.

Who Is Affected in Romania

Recent studies (2025):

<5% of .gov.ro domains have MTA-STS configured
<10% of large e-commerce domains (.ro) have MTA-STS
Comparison: 65% of DACH domains (Germany, Austria, Switzerland) have MTA-STS — a major competitive gap

For regulated organizations (NIS2 essential entities, financial sector DORA, healthcare GDPR), the absence of MTA-STS is one of the first gaps flagged by auditors.

Check Now

ARTEMIS automatically detects missing MTA-STS + DKIM + SPF + DMARC + DNSSEC + 30 other checks at 2-40 EUR per scan.

🔗 Complementary CAI Technology Solutions

ARTEMIS — Automatic technical verification MTA-STS + entire email stack + headers + TLS + 30+ tests.
Lexnomia — Auditor-grade NIS2 / GDPR / DORA assessment. For essential entities needing an official report for DNSC or auditors.
BeLegal — Free 5-minute compliance check.
Auditope — Holistic web audit (SEO + AI search + GDPR).
AriaUnited — EU funds PNRR/POIDS consultancy for secure email infrastructure implementation.

tehnic@caitech.ro