MTA-STS

This guide is part of our guide to email authentication. Related: BIMI and DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) is a standard that lets a domain require inbound mail be delivered over encrypted, authenticated TLS, preventing downgrade and man-in-the-middle attacks. TLS-RPT is its companion reporting standard, collecting daily reports on delivery TLS failures. MTA-STS protects the transport layer, complementing SPF, DKIM and DMARC, which authenticate the sender rather than the connection.

The problem MTA-STS solves

When two mail servers exchange messages over SMTP, they normally negotiate encryption using STARTTLS. The catch is that STARTTLS is opportunistic: the sending server asks whether the receiver supports TLS, and if the answer is no, it quietly falls back to plaintext. That question and answer happen in the clear, which means an attacker positioned between the two servers can strip the STARTTLS command from the conversation. The sending server then believes the receiver has no TLS support and delivers the message unencrypted, or connects to an impostor server presenting a forged certificate.

These are known as downgrade and man-in-the-middle attacks. Because SMTP was designed for interoperability first and security later, there was historically no way for a receiving domain to say “always encrypt mail to me, and refuse to deliver if you can’t.” MTA-STS fills exactly that gap. It lets a domain publish a policy declaring that inbound mail must be delivered over TLS, using a valid certificate that matches one of its published MX hosts. Sending servers that support MTA-STS honor the policy and will defer or bounce a message rather than send it in cleartext.

How MTA-STS works

MTA-STS relies on two pieces working together: a DNS TXT record that advertises the policy, and an HTTPS-hosted policy file that defines it.

First, publish a TXT record at _mta-sts.yourdomain.com. This record signals that a policy exists and carries an ID that changes whenever you update the policy, so sending servers know when to refetch it.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Second, serve the policy file over HTTPS at a fixed, well-known location: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The HTTPS requirement matters because the certificate on that host proves the policy is authentic and hasn’t been tampered with in transit.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

The mx lines list every hostname allowed to receive your mail, matching your MX records. max_age tells sending servers how long to cache the policy, in seconds (604800 is one week). A longer cache is more resistant to an attacker who can briefly manipulate DNS, so a value of at least a few days is recommended once you’re confident in your setup.

Enforce vs testing mode

The mode field in the policy file controls how strictly the policy is applied, and it is the single most important dial when rolling out MTA-STS.

Start with mode: testing. In testing mode, sending servers evaluate your policy but never block delivery when it fails. Instead, combined with TLS-RPT below, they report failures back to you. This lets you discover misconfigured MX hosts, expired certificates, or hostname mismatches without ever losing a legitimate message.

Once your reports come back clean for a week or two, switch to mode: enforce. Now sending servers will refuse to deliver mail that can’t be sent over authenticated TLS to a listed MX host. A third value, mode: none, effectively disables the policy and is used to gracefully retire MTA-STS. Always move testing to enforce deliberately, never the reverse in a hurry.

TLS-RPT: reporting

MTA-STS on its own tells you nothing about how delivery is going. TLS-RPT (SMTP TLS Reporting) is the feedback channel. You publish a second TXT record at _smtp._tls.yourdomain.com naming an address that should receive aggregate reports.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Participating sending servers send you a daily JSON report summarizing successful and failed TLS sessions to your domain, including the reason for each failure, such as a certificate that didn’t validate or a STARTTLS negotiation that was stripped. These reports are what make testing mode useful, and they remain valuable in enforce mode as an early warning system for certificate expiry or MX changes. Many teams route the rua address into a monitoring dashboard rather than a human inbox.

Where it fits alongside SPF, DKIM and DMARC

It’s easy to lump MTA-STS in with the other acronyms, but it solves a different problem. SPF, DKIM and DMARC authenticate the sender, answering “is this message really from the domain it claims?” MTA-STS secures the connection, answering “is this message being delivered privately and to the right server?” You want both. A message can be perfectly authenticated yet still be intercepted in transit, and a perfectly encrypted connection can still carry a spoofed message.

For the full picture of sender authentication, see our guide to email authentication. MTA-STS pairs naturally with those standards as a transport-layer addition, and once you have them in place, BIMI is another advanced layer worth considering, letting you display a verified brand logo in supporting inboxes.

Frequently Asked Questions

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) is a standard that lets a domain require inbound email be delivered over encrypted, authenticated TLS. It publishes a DNS record and an HTTPS-hosted policy file so sending servers enforce encryption and refuse to fall back to plaintext, blocking downgrade and man-in-the-middle attacks against SMTP.

What is the difference between MTA-STS and TLS-RPT?

MTA-STS is the enforcement standard: it defines the policy that requires TLS delivery. TLS-RPT is the reporting standard: it defines a DNS record and JSON report format so sending servers send you daily summaries of TLS delivery successes and failures. You deploy them together, using TLS-RPT to safely validate an MTA-STS policy before enforcing it.

Is MTA-STS required?

No, MTA-STS is not mandatory, and email works without it. However, it is strongly recommended for any domain that handles sensitive mail, because it closes a real gap that SPF, DKIM and DMARC do not address. Deploying it in testing mode first carries no delivery risk, so there is little reason not to adopt it.

Does MTA-STS replace SPF, DKIM or DMARC?

No. MTA-STS operates at a different layer. SPF, DKIM and DMARC authenticate the sender and detect spoofing, while MTA-STS secures the transport connection so mail is delivered privately to the correct server. They are complementary controls, and a well-protected domain deploys all of them together rather than choosing one over another.