The other half of email security.
DMARC, SPF and DKIM prove who sent a message. MTA-STS and TLS-RPT prove it reached you encrypted and untampered. Here is the transport-security layer, and how to turn it on without breaking mail.
Email encryption is opt-in, and strippable.
When one mail server hands a message to another, it tries to use TLS. But that attempt is opportunistic: if encryption is not on offer, the servers quietly fall back to plaintext and deliver anyway. An attacker sitting on the network can force exactly that, stripping the TLS offer so the message travels in the clear, then reading or altering it. Neither server is alerted.
MTA-STS removes the fallback: it tells senders that plaintext is not acceptable for your domain, and that mail must go only to the servers you name. TLS-RPT gives you the daily reports to prove it is working. Together they close a gap that identity checks like DMARC never touch.
One enforces. One reports.
MTA-STS
The rule.
A published policy that says: deliver to me only over TLS, and only to these MX hosts. A sender that cannot meet it refuses to fall back to plaintext. This is what actually stops the downgrade.
TLS-RPT
The feedback.
Daily aggregate reports from sending servers on how many connections negotiated TLS, and how many failed. It is the visibility that lets you enforce MTA-STS without guessing, and catch a regression before it bites.
Turn it on without breaking mail.
Reporting first, enforcement last. The same discipline as a DMARC rollout: never enforce what you cannot yet see.
01
Publish TLS-RPT first
Turn on reporting before you change anything. You start receiving daily summaries of how many connections to your mail servers negotiated TLS, and how many did not.
02
Publish MTA-STS in testing
Add the policy and the DNS record in mode: testing. Senders check the policy and report failures, but still deliver. You watch the reports for anything that would break.
03
Switch to enforce
Once the reports are clean, change the policy to mode: enforce. A sender that cannot establish TLS to one of your named MX hosts now refuses to deliver, rather than fall back to plaintext.
Two layers, two attacks.
Transport security does not replace identity. It covers the attack identity cannot.
Identity
DMARC, SPF, DKIM
Prove who a message is from. Stop someone forging your domain to impersonate you.
Transport
MTA-STS, TLS-RPT
Prove how a message travelled. Stop someone reading or altering it in transit.
Identity comes first: it is the bigger, more common attack, and it is where enforcement starts. Get your domain to p=reject, then close the transport gap on top.
What it takes.
Three records, one of which is a file you have to host, and keep in sync with your real MX. This is the fiddly part.
_mta-sts TXT
The policy pointer
A DNS TXT record at _mta-sts.yourdomain carrying a version and a policy id. When the policy changes, the id changes, and senders know to re-fetch it.
policy file
The policy, over HTTPS
A file served at https://mta-sts.yourdomain/.well-known/mta-sts.txt on a valid certificate. It lists your MX hosts and the mode: testing, or enforce.
_smtp._tls TXT
The reporting endpoint
A DNS TXT record at _smtp._tls.yourdomain naming where daily TLS reports go. This is the feedback loop that makes enforcing safe.
# _mta-sts.yourcompany.com (DNS TXT)
v=STSv1; id=20260713T000000Z
# https://mta-sts.yourcompany.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.yourcompany.com
max_age: 604800
# _smtp._tls.yourcompany.com (DNS TXT)
v=TLSRPTv1; rua=mailto:tls-reports@yourcompany.comThe fiddly part, handled.
Authex hosts the MTA-STS policy file, rotates the id on every change, and keeps the named MX hosts aligned with your real records so the policy never blocks your own mail. It ingests the TLS-RPT reports and flags a regression before it costs you delivery. The same Agent that runs your DMARC to enforcement runs this alongside it.
Questions, answered.
What is MTA-STS?
MTA-STS lets your domain tell sending mail servers to deliver to you only over an encrypted TLS connection, and only to the MX hosts you name. It closes two gaps in ordinary email delivery: an attacker stripping encryption to read mail in transit, and an attacker redirecting mail to a server you do not control. It is published as a DNS record plus a policy file served over HTTPS.
What is TLS-RPT?
TLS-RPT, or SMTP TLS Reporting, is the feedback channel for transport security. You publish a DNS record naming a reporting address, and sending servers return daily aggregate reports of how many connections succeeded or failed to negotiate TLS, including any MTA-STS policy failures. It is what lets you see a problem before you enforce a policy that would block mail.
What's the difference between MTA-STS and DMARC?
They defend against different attacks. DMARC, with SPF and DKIM, authenticates who a message is from, stopping someone forging your domain. MTA-STS secures how the message travels, stopping someone stripping the encryption or redirecting the delivery. One protects identity, the other protects the connection. A domain needs both, and neither substitutes for the other.
Do I need MTA-STS if I already have DMARC?
Yes. DMARC does nothing about encryption in transit. A message can pass DMARC perfectly and still be read or altered by an attacker who downgrades the TLS connection between mail servers. MTA-STS is the control that closes that gap, and TLS-RPT tells you whether it is holding. They sit alongside DMARC, not instead of it.
How do I deploy MTA-STS without breaking mail?
In stages, and reporting first. Publish TLS-RPT so you can see TLS outcomes, then publish MTA-STS in testing mode so senders check the policy and report failures but still deliver. Watch the reports until they are clean, then switch the policy to enforce. Skipping the testing stage risks blocking legitimate mail to a misconfigured or unlisted MX host.
What is a TLS downgrade attack?
Ordinary email encryption is opportunistic: mail servers try TLS but fall back to plaintext if it is not available. An attacker positioned on the network can strip the TLS offer so the servers fall back, then read or modify the message, and neither side is alerted. MTA-STS defeats this by telling senders that plaintext fallback is not acceptable for your domain.
Prove who. Then prove how.
Scan your domain free to see which protocols you publish today, then let the Agent run the whole stack.
Free · No signup