MTA-STS and TLS-RPT: Enforcing Encrypted Email Delivery

When one mail server hands a message to another, it is supposed to negotiate an encrypted TLS connection first. In practice, the encryption is optional and entirely best-effort: the sending server asks "do you support STARTTLS?" in plaintext, and if anything interferes with that question or the answer, it quietly falls back to delivering the message unencrypted. That gap is exactly what MTA-STS and TLS-RPT exist to close, and together they turn opportunistic encryption into something you can actually enforce and monitor.

This guide explains the downgrade problem in concrete terms, then walks through what MTA-STS is, what TLS-RPT adds, how the two standards complement each other, and how to publish and test them safely on your own domain.

SMTP between mail servers uses a mechanism called STARTTLS to upgrade a plaintext connection to an encrypted one. The fundamental weakness is that the negotiation happens in the clear. A sending server connects, the receiving server advertises STARTTLS as a supported command, and only then does encryption begin. Everything up to that point is visible and modifiable by anyone in the network path.

This enables a downgrade attack. An attacker positioned between the two servers, for example on a compromised router or a malicious upstream network, simply strips the STARTTLS keyword from the receiving server's capability list or corrupts the TLS handshake. The sending server sees no offer of encryption, concludes the recipient does not support it, and delivers the email in plaintext. Because classic SMTP TLS is opportunistic by design, the sender treats this silent fallback as normal rather than as an attack, so the message and its attachments travel readable across the internet.

A second, subtler risk is the absence of authentication. Even when TLS is used, traditional SMTP does not require the receiving server to present a valid certificate matching its hostname. An attacker can therefore impersonate the destination with a self-signed or mismatched certificate, intercept the connection, and read everything. MTA-STS addresses both the stripping and the impersonation problem.

MTA-STS (SMTP MTA Strict Transport Security, defined in RFC 8461) lets a domain publish a policy that says: "mail destined for me must be delivered over TLS, with a valid certificate, to one of these named mail servers." Sending servers that support MTA-STS discover and cache that policy, and once they have it, they refuse to deliver over an unencrypted or unauthenticated connection. A stripped STARTTLS no longer triggers a silent fallback; it triggers a delivery failure, which is the safe outcome.

MTA-STS is deliberately built on two channels that an in-path attacker cannot easily tamper with. The first is a DNS TXT record that signals a policy exists; the second is the policy file itself, which is served over HTTPS. Because the policy arrives over an authenticated, encrypted HTTPS connection, an attacker on the SMTP path cannot forge or suppress it without also defeating the web PKI.

MTA-STS has two parts that must both be present. The first is a DNS TXT record at "_mta-sts.yourdomain.com" with a value like "v=STSv1; id=20260626120000". The "id" is an opaque version string, typically a timestamp, that you change every time you update the policy file. Sending servers watch this record: when the id changes, they know to re-fetch the policy. Publishing the record is cheap, so you can confirm it resolves with our DNS Lookup lookup before moving on.

The second part is the policy file, served over HTTPS at the fixed URL "https://mta-sts.yourdomain.com/.well-known/mta-sts.txt". That subdomain must have a valid TLS certificate. The file is plain text and looks like this: "version: STSv1", "mode: enforce", one "mx:" line per mail host (wildcards such as "*.mail.yourdomain.com" are allowed), and "max_age:" in seconds. The "mode" field is the key control: "testing" reports problems without blocking mail, "enforce" actually refuses non-compliant delivery, and "none" withdraws the policy. The "mx" entries must match the hosts in your real MX records, so cross-check them with the MX Lookup tool before you enforce. The "max_age" tells senders how long to cache the policy, commonly between 86400 (one day) while testing and 604800 (one week) or more once stable.

MTA-STS can make TLS mandatory, but on its own it gives you almost no visibility. If a sending server suddenly cannot deliver to you because of a certificate mismatch, an expired certificate, an unsupported protocol version, or a stripped STARTTLS, you would only find out from bounce complaints. TLS-RPT (SMTP TLS Reporting, RFC 8460) fills that gap.

TLS-RPT is a single DNS TXT record at "_smtp._tls.yourdomain.com" whose value names where reports should be sent, for example "v=TLSRPTv1; rua=mailto:[email protected]". The "rua" tag can also point to an HTTPS endpoint. Participating senders then send you a daily aggregate report, in JSON, summarizing how many connections to your domain succeeded over TLS and how many failed, broken down by failure type and sending source. These reports are what let you turn MTA-STS on safely: they tell you whether real senders can complete a TLS handshake before you flip into enforce mode. Validate the record after publishing with the TLS-RPT Check checker.

The two standards are designed as a pair: MTA-STS is the enforcement mechanism, and TLS-RPT is the feedback loop. MTA-STS declares the rule ("deliver to me only over authenticated TLS"), while TLS-RPT reports on how well that rule is being met in the wild. Deploying MTA-STS without TLS-RPT means enforcing a policy blind; deploying TLS-RPT without MTA-STS means watching TLS health without the power to require it.

The conceptual relationship mirrors SPF/DKIM and DMARC. Just as DMARC's aggregate reports let you observe authentication results before enforcing a policy, TLS-RPT lets you observe transport-encryption results before enforcing MTA-STS. If you are still building out your email security posture, it is worth completing DMARC first; you can review its policy with the DMARC Check tool, then add the transport layer that MTA-STS and TLS-RPT provide.

1. Publish the TLS-RPT record first. Create the TXT record at "_smtp._tls.yourdomain.com" with "v=TLSRPTv1; rua=mailto:[email protected]". This costs you nothing operationally and immediately starts the flow of reports, giving you baseline data before any enforcement.

2. Host the policy file. Stand up the "mta-sts.yourdomain.com" subdomain with a valid TLS certificate and serve the file at "/.well-known/mta-sts.txt". Set "mode: testing" for now, list your real MX hosts under "mx:", and pick a modest "max_age:" such as 86400. Confirm the file loads cleanly over HTTPS in a browser.

3. Publish the MTA-STS TXT record. Add "_mta-sts.yourdomain.com" with "v=STSv1; id=...", using a fresh timestamp as the id. At this point the policy is discoverable and in testing mode, so supporting senders will report TLS failures via TLS-RPT but will not block any mail.

4. Monitor in testing mode. Watch your TLS-RPT reports for one to four weeks. They will reveal whether any legitimate senders are failing the TLS handshake, often due to a certificate that does not cover all your MX hostnames or an MX entry that does not match the policy.

5. Switch to enforce. Once reports show consistent TLS success, change the policy file to "mode: enforce", bump the "id" in the TXT record so caches refresh, and consider raising "max_age". From now on, supporting senders will refuse to deliver to your domain over a stripped or unauthenticated connection.

Never publish "mode: enforce" as your first step. In enforce mode, any mismatch between your policy and reality, such as a certificate that omits a mail hostname, an MX record you forgot to list, or an outdated TLS configuration, causes legitimate inbound mail to be rejected rather than merely logged. Testing mode lets you discover and fix every such issue from the TLS-RPT reports while mail keeps flowing normally. Treat the testing-then-enforce progression as mandatory, not optional.

Adoption matters because MTA-STS only helps when the sending server honours it. The good news is that the largest providers do. Google (Gmail and Google Workspace) enforces MTA-STS policies on outbound mail and sends TLS-RPT reports, and Microsoft (Outlook.com and Microsoft 365) honours MTA-STS as a sender and is rolling out reporting. Because these two account for an enormous share of email, publishing a policy meaningfully protects a large fraction of the mail sent to your domain even though MTA-STS support is not yet universal.

After each change, verify the moving parts independently. Use the MTA-STS Check checker to confirm the "_mta-sts" TXT record is present, the HTTPS policy file is reachable with a valid certificate, and the policy's "mx" entries match your actual mail servers. A common failure is a policy that enforces TLS to a hostname your certificate does not cover, which the checker will surface before it costs you delivered mail.

Confirm the reporting side with the TLS-RPT Check tool, which validates the "_smtp._tls" TXT record and the "rua" destination. It is also worth re-running the MX Lookup lookup whenever you change mail providers, since your MTA-STS policy must be kept in sync with your live MX records. Together, MTA-STS and TLS-RPT close the long-standing gap between "we support encryption" and "we require and can verify encryption" for every message sent to your domain.