MTA-STS
What is MTA-STS?
MTA-STSAn email security mechanism defined in RFC 8461 that lets a domain require TLS for inbound SMTP and pin a list of trusted MX hostnames, defeating downgrade and STARTTLS-stripping attacks.
MTA Strict Transport Security (MTA-STS), specified in RFC 8461, lets a domain publish a TXT record at _mta-sts.example.com and an HTTPS-fetched policy at https://mta-sts.example.com/.well-known/mta-sts.txt declaring required TLS, allowed MX hostnames, and a mode (none, testing, enforce). Sending MTAs cache the policy and, when in enforce mode, refuse to deliver mail if STARTTLS, certificate validation, or MX matching fails. MTA-STS complements DANE/TLSA for operators without DNSSEC and addresses opportunistic-TLS weaknesses where active attackers strip STARTTLS or present rogue certificates. SMTP TLS Reporting (RFC 8460) provides daily JSON reports of TLS failures to monitor coverage and incidents.
● Examples
- 01
Publishing an enforce-mode policy that limits inbound SMTP to mx1.example.com and mx2.example.com over TLS 1.2+.
- 02
Receiving daily TLSRPT reports showing zero TLS failures after a successful MTA-STS rollout.
● Frequently asked questions
What is MTA-STS?
An email security mechanism defined in RFC 8461 that lets a domain require TLS for inbound SMTP and pin a list of trusted MX hostnames, defeating downgrade and STARTTLS-stripping attacks. It belongs to the Network Security category of cybersecurity.
What does MTA-STS mean?
An email security mechanism defined in RFC 8461 that lets a domain require TLS for inbound SMTP and pin a list of trusted MX hostnames, defeating downgrade and STARTTLS-stripping attacks.
How does MTA-STS work?
MTA Strict Transport Security (MTA-STS), specified in RFC 8461, lets a domain publish a TXT record at _mta-sts.example.com and an HTTPS-fetched policy at https://mta-sts.example.com/.well-known/mta-sts.txt declaring required TLS, allowed MX hostnames, and a mode (none, testing, enforce). Sending MTAs cache the policy and, when in enforce mode, refuse to deliver mail if STARTTLS, certificate validation, or MX matching fails. MTA-STS complements DANE/TLSA for operators without DNSSEC and addresses opportunistic-TLS weaknesses where active attackers strip STARTTLS or present rogue certificates. SMTP TLS Reporting (RFC 8460) provides daily JSON reports of TLS failures to monitor coverage and incidents.
How do you defend against MTA-STS?
Defences for MTA-STS typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for MTA-STS?
Common alternative names include: MTA Strict Transport Security.
● Related terms
- network-security№ 1098
STARTTLS
An SMTP, IMAP, POP3, and XMPP extension defined in RFC 3207 that upgrades a plaintext connection to TLS after the protocol greeting, enabling opportunistic encryption between mail servers and clients.
- network-security№ 764
Opportunistic TLS
An encryption posture in which two parties use TLS when both support it and fall back to plaintext otherwise, typical of SMTP between mail servers using STARTTLS without strong authentication.
- network-security№ 270
DANE
A protocol family defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS server certificates or public keys to a service, removing reliance on the public CA system.
- network-security№ 333
DMARC
An email authentication standard defined in RFC 7489 that lets domain owners publish a policy telling receivers what to do with messages that fail SPF or DKIM and aligned domain checks.
- network-security№ 1159
TLS (Transport Layer Security)
The IETF-standardized cryptographic protocol that provides confidentiality, integrity, and authentication for traffic between two networked applications.
- network-security№ 984
Secure Email Gateway
A perimeter or cloud service that filters inbound and outbound email for spam, phishing, malware, data leakage, and policy violations before it reaches user mailboxes.