MTA-STS
MTA-STS lets a domain declare that mail sent to it must arrive over TLS, to a named set of hosts. The policy is published as a file on an HTTPS host and announced by a TXT record in DNS. A sending server that supports it fetches and caches the policy, then refuses to deliver over an unencrypted or mismatched connection rather than falling back.
At a glance
- Category
- Transport security
- Announced by
- A TXT record at _mta-sts.<domain>
- Policy served at
- https://mta-sts.<domain>/.well-known/mta-sts.txt
- Modes
- none, testing, enforce
- Protects against
- Downgrade attacks on opportunistic TLS
- Specified in
- RFC 8461
How it works
The domain publishes a policy file over HTTPS listing the MX hostnames that may accept its mail, a mode and a lifetime, and a TXT record whose identifier changes whenever the policy does. A sending server that supports MTA-STS sees the record, fetches the policy over a connection whose certificate already proves the domain, and caches it for the stated lifetime. From then on it will only deliver to a listed host over TLS with a valid certificate. In enforce mode, anything else is a failure rather than a fallback.
Why it matters
Ordinary TLS between mail servers is opportunistic: the receiving server offers encryption and the sender takes it if it can. An attacker in the path can simply strip that offer and watch the session downgrade to plain text, and neither side notices. MTA-STS removes the fallback by moving the declaration out of the interceptable channel and onto a host authenticated by the web public key infrastructure. It is the practical alternative for operators who do not run DNSSEC.
Example
A domain publishes a policy in testing mode listing its two MX hostnames with a lifetime of a week, plus the announcing TXT record. Reports from senders show every connection already negotiating TLS successfully, so after a month the mode is changed to enforce and the record's identifier is updated so caches refetch. A sending server that now finds a certificate mismatch on one of the hosts refuses to deliver rather than sending in the clear.
Common mistakes
- 01Switching straight to enforce without a testing period, so one stale certificate silently stops inbound mail.
- 02Changing the policy file without changing the identifier in the TXT record, so senders keep using the cached version.
- 03Listing a hostname that is not in the MX records, which makes the policy unusable for the host the sender actually contacts.
Related terms
Frequently asked questions
Does MTA-STS protect mail I send or mail I receive?
Mail you receive. Your policy tells other senders how they must connect to you. Protecting your outbound mail depends on the recipient domain publishing its own policy.
How is it different from DANE?
Both remove the downgrade fallback, but DANE anchors trust in DNSSEC while MTA-STS anchors it in the web certificate authorities. Operators without DNSSEC can deploy MTA-STS today.
Should I start in testing mode?
Yes. Testing mode reports failures without blocking delivery, which is exactly what you want while confirming that every listed host presents a valid certificate.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.