MTA-STS and TLS-RPT explained

MTA-STS and TLS-RPT are the two records that make encryption of inbound mail to your domain enforceable and visible. SMTP’s built-in encryption (STARTTLS) is opportunistic — an attacker on the network can strip it, and mail silently falls back to plaintext. MTA-STS tells sending servers to require TLS and refuse to deliver if it can’t be established securely, closing that downgrade hole. TLS-RPT gives you daily reports of when TLS negotiation succeeds or fails, so you can see problems instead of guessing. This guide shows both records and the policy file.

Written & reviewed by the VerifyAnyEmail team · Last reviewed July 2026

If you only remember one thing: MTA-STS forces senders to use verified TLS when delivering to you (no silent downgrade to plaintext), and TLS-RPT emails you a daily report of how that’s going. They protect mail coming in to your domain, they’re independent of SPF/DKIM/DMARC, and together they cost nothing but a couple of DNS records and one static file served over HTTPS.

The problem they solve

When one mail server delivers to another, it normally upgrades the connection to TLS using STARTTLS. But that upgrade is opportunistic: if the encryption fails, or an on-path attacker strips the STARTTLS command, the sending server just delivers over plaintext instead — and there’s no policy telling it not to. An attacker can also present a fraudulent MX or certificate and the sender has no way to know it should have refused. MTA-STS (RFC 8461) fixes this by letting you publish a policy that says “mail to my domain must use TLS, to these MX hosts, with a valid certificate — and if that can’t be done, don’t deliver.” TLS-RPT (RFC 8460) is the companion that reports on it.

MTA-STS: the DNS record

MTA-STS has two parts: a small TXT record that announces a policy exists, and the policy file itself served over HTTPS. The TXT record lives at _mta-sts.yourdomain.com:

_mta-sts.example.com  TXT
  "v=STSv1; id=20260721000000Z"
  • v=STSv1 — the version.
  • id= — an opaque policy identifier. Change this value every time you change the policy file so sending servers know to re-fetch it. A timestamp is a common convention.

This record deliberately contains no policy details — it only tells a sender “a policy exists, go fetch it.”

MTA-STS: the policy file

The actual policy is a plain-text file that must be served at exactly this URL, over HTTPS with a valid certificate:

https://mta-sts.example.com/.well-known/mta-sts.txt

Note the host is mta-sts.yourdomain.com (you’ll need a DNS record and TLS cert for that subdomain) and the path is fixed. The file contents look like this:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800
  • mode: — enforce (reject delivery if TLS can’t be verified), testing (don’t block, but do report failures via TLS-RPT), or none (disable).
  • mx: — one line per MX host permitted to receive your mail; wildcards are allowed. These must match your actual MX records.
  • max_age: — how long, in seconds, senders may cache this policy (up to about a year; a week, 604800, is common).

Roll out in testing mode first

Never publish mode: enforce as your first step. If your MX list or certificate has a problem, enforce mode causes senders to reject mail to you — you’d block your own inbound email. Start in testing mode, which changes nothing about delivery but makes senders report any TLS failures through TLS-RPT:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800

Run testing for a couple of weeks while you watch the TLS-RPT reports. Once they show TLS succeeding consistently across senders with no failures, change mode: to enforce and bump the id= in the TXT record so servers pick up the new policy. This mirrors the staged approach you’d use for DMARC — observe before you enforce.

TLS-RPT: the reporting record

TLS-RPT is a single TXT record that asks sending servers to send you daily summaries of TLS negotiation with your domain — successes and failures, including the reason for any failure. It lives at _smtp._tls.yourdomain.com:

_smtp._tls.example.com  TXT
  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
  • v=TLSRPTv1 — the version.
  • rua= — where the reports go. A mailto: is typical; an https:// endpoint is also allowed. You can list more than one, comma-separated.

TLS-RPT is useful on its own, even without MTA-STS or DANE — it simply gives you visibility into whether inbound mail is being encrypted and, if not, why. Publish it early: it’s the feedback loop that tells you it’s safe to move MTA-STS from testing to enforce, and it keeps warning you if a certificate later expires or an MX changes.

Reading the reports

TLS-RPT reports arrive as JSON, one per sending organisation per day, summarising how many sessions used TLS successfully and detailing any failures — expired certificate, certificate host mismatch, STARTTLS stripped, policy fetch error, and so on. In testing mode these reports are how you confirm every legitimate sender can establish verified TLS before you switch to enforce. After you enforce, they remain a monitoring tool: a spike in failures usually means a certificate lapsed or an MX/policy mismatch that needs fixing before it starts blocking mail.

Putting it together

A sensible order: publish the TLS-RPT record first so you have visibility, publish MTA-STS in testing mode, watch the reports for a couple of weeks, then promote MTA-STS to enforce and update the id=. Whenever you change MX hosts or the policy file, update id= so caches refresh. Verify the MTA-STS TXT record, the policy file at its .well-known URL, and the certificate all line up with the MTA-STS Checker, and confirm your reporting record is valid with the TLS-RPT Checker. The authoritative specs are RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT).

Check your domain in seconds

Run the free diagnostics referenced in this guide — no sign-up needed.

Email Health CheckAll tools

More guides

🧹 How to Clean an Email List Before a Campaign (2026 guide)
A step-by-step workflow to dedupe, validate and verify a list before you hit send — and keep bounces low.
🔬 How Email Verification Works (Without Sending an Email)
Syntax → MX → live SMTP probe → catch-all/role/disposable checks: the real pipeline, explained.
🚦 Deliverable, Risky, Catch-All & Unknown: How to Handle Every Verification Result
What each verification status means and the safe action to take — from sign-up forms to bulk sends.
🎯 Should You Send to Catch-All Emails? (2026)
Catch-all domains accept everything, so SMTP can’t confirm the mailbox. A practical decision framework.