MTA-STS and TLS-RPT: The Email Security Everyone Ignores

Most teams have heard the SPF/DKIM/DMARC trio so often it has become background noise. They configure all three, hit a 95% DMARC pass rate, and consider email security solved. It is not. There is an entire layer below DMARC where messages can still be intercepted in transit, and almost nobody configures the two standards designed to prevent it: MTA-STS (RFC 8461) and TLS-RPT (RFC 8460).

This article explains what these two standards actually do, what attack they stop, how to publish them correctly, and how to read the reports you will start receiving. If you ship sensitive transactional email — password resets, invoices, healthcare notifications — you really need to read this.

The Attack You Are Not Protecting Against

When server A sends mail to server B, the SMTP handshake starts in cleartext. Server A issues STARTTLS and the conversation upgrades to TLS. The problem: nothing forces server A to insist on TLS. If an attacker on the network strips the STARTTLS response, the sending server happily falls back to plaintext. Your password reset email is now visible to anyone with a passive tap.

This is called a STARTTLS downgrade attack, and it has been observed in the wild against entire countries — most famously documented by Google researchers in 2014 when they noticed a country-wide stripping of STARTTLS from outgoing Gmail mail.

Why Not Just Require TLS?

Because the SMTP transport is opportunistic by design. The receiving server has no standard way to say "I always support TLS, never trust a plaintext fallback from my server". Until MTA-STS, there was no answer to the question "is this server lying to me about its TLS support?"

What MTA-STS Actually Does

MTA-STS lets a domain publish a policy that says: "any sender that talks to my MX servers MUST do so over TLS with a valid certificate matching one of these names". The policy is fetched over HTTPS, so it cannot be stripped by an on-path attacker.

The mechanics are simple. You publish three things:

1. A TXT record at _mta-sts.example.com announcing the policy version.
2. An HTTPS endpoint at https://mta-sts.example.com/.well-known/mta-sts.txt serving the policy file.
3. A valid certificate on that HTTPS endpoint covering mta-sts.example.com.

The TXT Record

_mta-sts.example.com. IN TXT "v=STSv1; id=20260516T1200;"

The id is an opaque identifier. Change it whenever you change the policy file. Senders cache by id.

The Policy File

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Three modes are defined:

• none: I am no longer publishing a policy. Senders may discard cached versions.
• testing: failures are reported via TLS-RPT but the message is delivered anyway. Use this for the first 2-4 weeks.
• enforce: failures are reported AND the message is rejected.

⚠️ Warning: Never deploy mode: enforce straight away. If your MX certificate is wrong, mail simply will not arrive. Always run in testing first and watch the TLS-RPT reports for two weeks.

What TLS-RPT Does

TLS-RPT is the diagnostic counterpart. It is a TXT record telling other mail servers where to send daily aggregate reports about TLS failures when contacting your domain.

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

You will receive JSON reports from Google, Microsoft, Yahoo and a handful of others. Each report looks like this:

{
  "organization-name": "Google Inc.",
  "date-range": { "start-datetime": "2026-05-15T00:00:00Z",
                  "end-datetime":   "2026-05-15T23:59:59Z" },
  "contact-info": "smtp-tls-reporting@google.com",
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "example.com" },
    "summary": { "total-successful-session-count": 4123,
                 "total-failure-session-count":     2 },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "74.125.83.27",
      "receiving-mx-hostname": "mx1.example.com",
      "failed-session-count": 2
    }]
  }]
}

Three failures a day on millions of messages is normal. Three hundred is an emergency.

Common Failure Modes

When you run MTA-STS in testing for two weeks, here are the most likely problems you will discover:

Deploying It Step by Step

Here is the safe rollout sequence:

1. Audit every MX host: confirm STARTTLS works, certs are public-CA, not expired, names match.
2. Publish TLS-RPT first. Watch the reports for a week to establish a baseline.
3. Deploy MTA-STS in mode: testing. Watch reports for 2-4 weeks.
4. Once you see zero genuine failures, switch to mode: enforce.
5. Keep max_age conservative (one week) until you are confident, then raise to 30 days.

The Hosting Detail Most People Miss

The MTA-STS policy file MUST be served over HTTPS with a publicly trusted certificate. A static page served by GitHub Pages, Cloudflare Pages or a small Caddy/nginx is enough. Do not serve it from a CDN that strips the .well-known path. Do not redirect to HTTP. Do not serve it with HSTS preload conflicts.

💡 Tip: A 5-line Caddy config does the job: mta-sts.example.com { root * /srv/mta-sts; file_server }. Free certificate, automatic renewal.

Does It Help With DMARC?

Indirectly, yes. DMARC depends on SPF and DKIM, both of which can be manipulated if an attacker can intercept and alter mail in transit. MTA-STS makes that interception detectable. It is a transport-layer guarantee, not an authentication one, but the two layers reinforce each other.

Cost-Benefit

MTA-STS takes about half a day to set up correctly and another two weeks to validate. The reward: silent eavesdropping of transactional email becomes impossible, your domain looks more credible to receivers, and you get continuous diagnostic data via TLS-RPT.

Target SMTP automatically publishes MTA-STS and TLS-RPT records for every domain provisioned in the platform, and the dashboard surfaces TLS-RPT failure trends alongside DMARC aggregate reports. The Send-Time Firewall can also halt outbound mail when a recipient domain has just changed its MTA-STS policy in a way that would fail enforcement, preventing surprise bounces during cert rotations.