What is MTA-STS and TLS-RPT?
MTA-STS (Mail Transfer Agent Strict Transport Security) closes a long-standing weakness in how mail servers connect: encryption between them is normally opportunistic and can be silently stripped by an attacker. MTA-STS lets a domain demand that incoming mail be delivered over a valid, encrypted connection, and its companion standard TLS-RPT gives you reports when delivery attempts fail. Together they protect mail in transit and tell you when something is wrong.
What MTA-STS is
MTA-STS, or Mail Transfer Agent Strict Transport Security, lets your domain insist that other servers deliver mail to you over an encrypted and authenticated TLS connection. Without it, encryption between mail servers is opportunistic: if the secure handshake fails or is tampered with, servers quietly fall back to sending mail in the clear. That gap lets an attacker on the network strip encryption and read or alter messages.
MTA-STS removes the silent fallback. A domain that publishes an enforcing policy is telling every sender that mail must be delivered securely or not at all.
How it works
MTA-STS has two parts that work together:
- A policy file served over HTTPS at
https://mta-sts.yourdomain/.well-known/mta-sts.txt. It lists the mail servers that should receive your mail and the enforcement mode (enforce,testing, ornone). - A TXT record at
_mta-sts.yourdomainthat signals the policy exists and carries a version identifier so senders know when it has changed.
The TXT record looks like this:
A sending server reads the TXT record, fetches the HTTPS policy, caches it, and then enforces valid TLS on delivery. Because the policy is fetched over HTTPS with a trusted certificate, an attacker cannot forge or downgrade it.
What TLS-RPT adds
MTA-STS can cause mail to be deferred when a secure connection cannot be made, but on its own it gives you no visibility into when that happens. TLS-RPT (SMTP TLS Reporting) fills that gap. It is a separate TXT record at _smtp._tls.yourdomain that asks sending servers to email you summary reports of their TLS connection results:
Those reports tell you whether senders are successfully negotiating TLS or hitting failures, which is essential for spotting certificate problems or misconfigured mail servers before they cause delivery loss.
Setup overview
- Host the policy file. Serve
mta-sts.txtover HTTPS at themta-stssubdomain, listing your mail servers and starting intestingmode. - Publish the MTA-STS TXT record. Add the
_mta-stsTXT record with a version and a uniqueid. - Add TLS-RPT. Publish the
_smtp._tlsTXT record pointing reports to a mailbox you monitor. - Move to enforce. Once reports confirm senders are negotiating TLS cleanly, switch the policy mode from
testingtoenforce, and bump theid.
Why it matters
MTA-STS and TLS-RPT protect the confidentiality and integrity of mail while it travels between servers, defending against active network attackers who would otherwise downgrade your connections. They complement, rather than replace, the sender-authentication work done by SPF, DKIM, and DMARC: authentication proves who sent a message, while MTA-STS protects it in transit. A well-secured mail domain wants both.