1. Vulnerabilities in Opportunistic STARTTLS (RFC 3207)
By default, SMTP mail routing between Transfer Agents (MTA-to-MTA) relies on Opportunistic TLS (RFC 3207). When a sending MTA issues a STARTTLS command on port 25, a Man-in-the-Middle (MitM) attacker on the network path can strip the STARTTLS capability response or inject negotiation errors. In response, conventional MTAs silently fall back to unencrypted cleartext transmission, exposing sensitive message payloads to wiretapping.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resolves this vulnerability by allowing domain owners to declare that inbound SMTP traffic must utilize TLS v1.2+ with valid, trusted X.509 certificates matching published MX hosts.
2. Structure of the HTTPS .well-known/mta-sts.txt Policy File
The MTA-STS policy file must be served strictly over HTTPS on the dedicated subdomain mta-sts.yourdomain.com at the standardized URI path /.well-known/mta-sts.txt.
mode: enforce— Mandates encrypted TLS connections and valid X.509 cert validation. If handshake fails, delivery is rejected.mode: testing— Logs TLS failures without blocking mail delivery. Recommended during initial rollout.max_age— Policy cache duration in seconds for sending MTAs (e.g., 604800s = 7 days).
3. Publishing DNS TXT Records & TLS-RPT Telemetry (RFC 8460)
To signal MTA-STS policy support and enable diagnostic reporting for TLS connection failures, publish the following DNS records: