SMTP was designed for servers to exchange mail, and for most of its life the transport was not encrypted. STARTTLS added encryption, but it is negotiated in plaintext, so an attacker on the path can remove the offer and force a downgrade. MTA-STS and TLS-RPT are two standards that help senders refuse to downgrade and report when TLS fails. This article covers what each one does, how they are published, and what can go wrong.
The problem
When a sending server connects to a receiver's MX host, it normally offers STARTTLS, and if the receiver advertises it, the sender upgrades. A network attacker can strip the STARTTLS line from the EHLO response. By default, many senders then deliver in plaintext without complaint. This is opportunistic encryption. It protects against passive eavesdropping, but not against an active attacker.
MTA-STS, defined in RFC 8461, lets a domain tell senders that they must use verified TLS when delivering to its mail servers. The policy is published over HTTPS, so the policy itself cannot be stripped in transit.
How MTA-STS is published
There are two parts. A DNS TXT record announces that a policy exists and gives a version identifier:
_mta-sts.example.com. IN TXT "v=STSv1; id=20261031120000"The policy is a text file served over HTTPS at a fixed URL:
https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800The mode field has three values. testing asks senders to report failures but still deliver. enforce requires TLS with a valid certificate that matches a listed MX host, and senders must not deliver otherwise. none removes the policy. The mx lines list the hosts the policy covers. max_age is how long, in seconds, a sender may cache the policy. The id in the DNS record must change whenever the policy changes, so that senders know to refetch it.
What senders check
A compliant sender looks up the TXT record and fetches the policy. For each MX host it connects to, it requires STARTTLS, checks that the certificate is valid and matches a name in an mx line, and checks the chain against trusted roots. Under enforce, a failure means the sender must not deliver to that host. Under testing, the sender delivers anyway and reports the failure.
The consequence is that certificates matter more. An expired certificate on an MX host becomes a delivery failure for senders that honour the policy. Plan renewals, and roll out from testing to enforce only after the reports are clean.
TLS-RPT
TLS-RPT, defined in RFC 8460, is the reporting half. It lets a receiver ask senders to send reports about TLS failures for its domain. A DNS record names where the reports should go:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"Reports are JSON, usually sent daily. They describe the sessions that succeeded and failed, the policy in force, and the reasons for failure, such as an expired certificate or a mismatched name. The rua value can be a mailto address or an HTTPS endpoint. The reports are the feedback loop. Without them, you learn about a broken TLS setup only when someone complains.
What is published for hosted domains
MTA-STS and TLS-RPT records are published for domains hosted on ITProMail. You can check them with dig +short TXT _mta-sts.yourdomain and dig +short TXT _smtp._tls.yourdomain. For what the hosted setup covers and what to check in your own zone, see MTA-STS.
Common mistakes
- Going straight to
enforce. Start withtesting, read the reports, and fix problems first. - Leaving an MX host out of the policy's mx lines.
- Changing the policy without changing the id in the DNS record, so caching senders never refetch it.
- Letting certificates expire. The policy depends on working TLS on every listed host.
- Serving the policy from a host with an invalid certificate. The policy fetch itself must use HTTPS with a valid certificate.
Why it matters
Encrypting mail between servers is only useful if the encryption cannot be quietly removed. MTA-STS turns "encrypt if possible" into "encrypt, or do not deliver" for senders that support it, and TLS-RPT shows you when that is causing failures. Neither replaces message-level encryption such as PGP, which protects content after the message has been stored. For the alternative route to the same goal, see DANE for email.