Back to field guides
Primer · MTA-STS · TLS-RPT

MTA-STS, TLS-RPT, and why most domains skip them.

9 min read·Updated 2026-04

Everybody talks about DMARC. Nobody talks about whether the mail in transit is encrypted. MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) are the answers, and they take about an afternoon each to stand up once you know what you're doing.

The hole MTA-STS plugs

When a sending mail server tries to deliver a message to your MX, it negotiates TLS opportunistically — the historical SMTP standard says “use TLS if both sides support it, otherwise plaintext is fine.” This is fine if both sides actually support it. It's catastrophic if a man-in-the-middle can downgrade the negotiation by stripping the STARTTLS announcement, in which case both servers happily fall back to plaintext SMTP and your mail traverses the internet in clear.

MTA-STS lets you say: “TLS is required when delivering to my mail. If you can't do TLS, drop the message.” A sender that respects MTA-STS (Gmail, M365, Yahoo, Fastmail, every modern mail provider) checks your published policy, fails closed if TLS can't be established, and reports the failure via TLS-RPT.

How it's implemented — two pieces

1. The TXT record

A TXT record at _mta-sts.<your-domain>:

_mta-sts.acme.com.   IN TXT  "v=STSv1; id=20260424093000"

2. The policy file

Hosted at https://mta-sts.<your-domain>/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 1209600

The policy must be served from a host namedmta-sts.<your-domain>, over HTTPS, with a valid certificate. The path must be exactly /.well-known/mta-sts.txt. Content-Type: text/plain.

TLS-RPT — the audit trail

Without TLS-RPT, MTA-STS is a black box: you know your policy says “require TLS,” but you have no idea who succeeded, who failed, who was downgraded. TLS-RPT (RFC 8460) fixes that — sending servers POST you a daily JSON report listing TLS attempts.

The DNS record:

_smtp._tls.acme.com.   IN TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@acme.com"

You receive a daily JSON report from each sending provider summarising TLS handshake results to your MX. A typical report looks like:

{
  "organization-name": "Google",
  "policies": [
    {
      "policy": { "policy-domain": "acme.com" },
      "summary": {
        "total-successful-session-count": 1247,
        "total-failure-session-count": 3
      },
      "failure-details": [{
        "result-type": "validation-failure",
        "failed-session-count": 3,
        "failure-reason-code": "X.509-cert-not-trusted"
      }]
    }
  ]
}

That tells you: 1,247 successful TLS sessions, 3 failures. The 3 failures had cert validation issues. Now you can fix the cert before flipping mode: enforce and quarantining real mail.

Why most domains skip them

The honest answer: nobody understands them, the setup is fiddly, and the immediate visible win is small. The consequences of a misconfiguration are scary (mail rejected for days). The cost of doing nothing is invisible — you don't see the messages getting downgraded to plaintext until somebody's wire transfer header gets intercepted.

The pattern: every CISO at a regulated org wants MTA-STS. Every operator under that CISO has been kicking the can on MTA-STS for two years because nobody owns “serve a static text file at a specific HTTPS URL.” It's infrastructure with no clear home.

The compliance angle

MTA-STS is becoming a contractual expectation in regulated industries: finance, healthcare, legal, insurance — especially anyone bound by HIPAA, GLBA, GDPR Article 32, or the various state-level data protection laws. Cyber-insurance underwriting now asks about it explicitly.

For most teams, “our cyber insurer started asking” is the moment MTA-STS goes from “we should” to “we must.” The catch is the policy file requirement — if your team has DNS but no web-server ownership, you need someone to host mta-sts.your-domain.com with a TLS cert. That coordination is what trips most rollouts.

The Mailstinger-managed option

We host both ends — CNAME mta-sts.your-domain.com to us, we serve the policy file with the right cache headers, manage theid bump on every change, and parse incoming TLS-RPT reports into a dashboard. The DNS edits are two records (the TXT + a CNAME); we own everything else.

That removes the “but who hosts the policy file?” coordination problem, which is what kills most MTA-STS rollouts.

How to roll it out without breaking mail

  1. Publish the TXT and policy file with mode: testing and max_age: 86400. Set mx entries to match your current MX.
  2. Publish the TLS-RPT TXT. Wait for a week of reports to arrive at your rua.
  3. Read the reports. Every TLS failure is a sender you don't want to silently lose mail from. Fix cert chains, MX hostname mismatches, etc., before tightening.
  4. Once a week passes with zero TLS failures, flipmode: enforce. Bump the id.
  5. After another month of stable enforcement, raisemax_age to 1209600 (14d) for the strong cache that protects against downgrade attacks.

Things people get wrong

Where to read next