MTA-STS and TLS-RPT Configuration: A Sender's Guide

You finished the part that actually moves your spam rate: SPF, DKIM, and DMARC are all passing and aligned. Now you're looking at two more acronyms, MTA-STS and TLS-RPT, and wondering whether they belong on the same checklist or whether they're security theater for people who like DNS records a little too much.

Here's the honest answer up front. MTA-STS and TLS-RPT configuration won't lift your cold-email placement the way authentication does. They live one layer down, at transport encryption, and they mostly protect mail coming into your domain rather than the campaigns going out. But they're cheap to set up, they close a real downgrade-attack hole, and the TLS-RPT feed catches transport problems your other reports never show you. For a sender who wants a mature, complete posture, they're worth an afternoon.

This guide assumes your authentication is already done. If it isn't, start with the SPF, DKIM, and DMARC guide, because nothing below substitutes for that. We'll walk only the transport-encryption layer: what these two records do, whether you need them, and the exact policy file and DNS entries to publish.

Key Takeaways

• MTA-STS lets your domain demand that senders use TLS with a valid certificate, and refuse to deliver if they can't. It's defined in RFC 8461.
• TLS-RPT is the companion reporting record. It asks senders to mail you a daily summary of every connection that succeeded or failed encryption, per RFC 8460.
• These protect inbound mail to your domain, including the replies your cold campaigns generate. Your outbound mail already honors other domains' MTA-STS policies automatically on Gmail and Microsoft 365.
• Adoption is still low: a September 2025 measurement of 10,000 frequently emailed domains found just 6% had MTA-STS published.
• Always start in testing mode, read the reports, and only switch to enforce once you've confirmed nothing legitimate is failing.

What MTA-STS and TLS-RPT actually do

SMTP encryption is opportunistic by default. Two mail servers connect, one offers STARTTLS, the other upgrades to an encrypted channel, and if the upgrade doesn't happen the message often goes through in plaintext anyway. That "anyway" is the problem. RFC 8461 spells it out: any attacker who can delete the 250 STARTTLS response or redirect the SMTP session "can perform downgrade or interception attacks." Strip the STARTTLS offer and the message falls back to cleartext, readable by anyone on the path.

MTA-STS removes the "anyway." It lets a receiving domain publish a policy that says, in effect: I support TLS, here are my real MX hosts, and if you can't get a valid encrypted connection to one of them, do not deliver. A sending server that supports MTA-STS reads that policy, caches it, and fails closed instead of falling back to plaintext. The mechanism relies on regular certificate authorities rather than DNSSEC, which is the practical difference from DANE: RFC 8461 notes that DANE "requires DNSSEC for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC." That's why most senders reach for MTA-STS first. No DNSSEC dependency.

TLS-RPT is the feedback loop. On its own, MTA-STS would fail silently: a misconfigured policy could quietly block real mail and you'd never know. TLS-RPT fixes that by asking every participating sender to mail you a daily report of how their TLS connections to your domain went, including the failures. You publish one small TXT record, and Gmail, Microsoft, and other large senders start sending you structured JSON summaries. Think of it as the transport-layer cousin of a DMARC aggregate feed: same idea, different data. Where a DMARC RUA report tells you who's authenticating as your domain, a TLS report tells you who couldn't encrypt to it. If you've set up the DMARC side, our guide on reading DMARC aggregate reports covers that feed; TLS-RPT is the separate, parallel one.

Do cold email senders actually need this?

Let me be straight, because most setup guides won't be. MTA-STS is not a deliverability lever. It won't change your Gmail spam rate, your inbox placement, or how Outlook scores your domain. Those are decided by authentication, reputation, and content, which the avoid spam filters guide covers. So if you're hoping a TLS policy fixes a placement problem, it won't, and you should run a proper deliverability audit instead.

What it does do is worth understanding clearly:

• Protects your reply traffic. Cold outreach that works generates replies, and those replies are inbound mail to your domain. MTA-STS keeps that conversation encrypted end to end, which matters more when prospects send you contracts, pricing, or anything sensitive.
• Gives you a transport-failure feed. TLS-RPT surfaces certificate expirations, MX misconfigurations, and downgrade attempts you'd otherwise be blind to. It's a free monitoring channel that pairs naturally with the rest of your domain health monitoring.
• Signals a mature sender. It won't win you a reputation bonus, but a domain running full authentication plus transport security looks like an operator, not a churn-and-burn sender.

The flip side: it's optional, and it carries a small operational risk. An enforced policy that points at the wrong MX host can block legitimate inbound mail. That's exactly why the rollout below is staged, never flipped straight to enforce.

One more clarification on the "enforce TLS for outbound email" question, because it confuses people. You don't configure your outbound TLS enforcement through MTA-STS. If you send from Google Workspace or Microsoft 365, your provider already honors recipients' MTA-STS policies on your behalf, automatically. Google states that messages from your domain "comply with MTA-STS when sent to external servers with an MTA-STS policy in enforced mode." Microsoft is even more explicit: outbound MTA-STS validation in Exchange Online "is therefore always turned on (like other core SMTP features)." So the records you publish are about protecting your inbox. The outbound side is handled for you.

The two records, side by side

MTA-STS and TLS-RPT are separate standards that work as a pair. Here's how they line up before we configure them.

The asymmetry is the key takeaway. TLS-RPT is one DNS record and zero risk, so publish it first and on its own if you want. MTA-STS needs an HTTPS-served policy file plus a DNS record, and it can actually refuse mail, so it gets the careful, staged rollout.

How to configure TLS-RPT first (the safe, easy one)

Start here because it can't break anything and the data it returns is what makes the MTA-STS rollout safe.

Publish a single TXT record at the _smtp._tls subdomain. The format from RFC 8460 is a version tag plus a rua field naming where reports go:

1_smtp._tls.yourdomain.com.  IN TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

A few specifics that matter:

• The rua field supports two URI schemes, mailto and https, per RFC 8460. Email is simplest. Use an HTTPS endpoint only if you're feeding a parser directly.
• You can list more than one destination, comma-separated. Google's own example uses rua=mailto:[email protected],mailto:[email protected].
• Reports arrive roughly daily. RFC 8460 says each report "SHOULD cover a full day, from 00:00-24:00 UTC," delivered as gzip-compressed JSON.

Send the reports to a dedicated mailbox or a parser, not your main inbox. Raw TLS reports are compressed JSON, and one busy domain can produce a steady drip of them. We'll cover what's actually inside them further down.

How to configure MTA-STS: the policy file setup

MTA-STS has two moving parts that must agree: a policy file served over HTTPS, and a DNS TXT record that points senders at it. Get them out of sync and senders either ignore the policy or cache a stale one.

Step 1: Publish the policy file

The policy is a plain-text file served from a fixed, predefined URL on a subdomain that starts with mta-sts. RFC 8461 fixes the location as https://mta-sts.{yourdomain}/.well-known/mta-sts.txt. Microsoft's own policy, for example, lives at https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

The file itself is four fields, one per line:

1version: STSv1
2mode: testing
3mx: *.mail.protection.outlook.com
4max_age: 604800

Field by field:

• version is always STSv1. It's the only value RFC 8461 defines.
• mode is one of none, testing, or enforce. You'll start at testing. More on the difference below.
• mx lists the MX host patterns allowed to receive your mail. The example above is the Microsoft 365 pattern. For Google Workspace you'd list the aspmx.l.google.com host family instead. Every legitimate MX host has to appear here, or mail to it fails validation. If you use a third party for inbound filtering, its hosts go here too.
• max_age is how long, in seconds, senders cache the policy. The example uses 604800, one week. RFC 8461 caps the value at 31557600 seconds, about a year, and recommends values "in the range of weeks or greater" so an attacker can't easily flush the cache.

Three hard requirements on the hosting, all from the spec, all easy to get wrong:

1. The policy must be served over HTTPS with a valid certificate for the mta-sts subdomain. Plain HTTP doesn't count.
2. The server must return HTTP 200. RFC 8461 is explicit that "HTTP 3xx redirects MUST NOT be followed," so a redirect from mta-sts.yourdomain to your main site will break the policy fetch.
3. It should respond quickly. Microsoft notes the policy-fetch timeout per RFC guidance is 60 seconds.

You don't need a full web server for this. A static host works fine, and Microsoft documents using Azure Static Web Apps precisely because it issues the TLS certificate for the subdomain automatically. The point is a tiny, reliable HTTPS endpoint that returns one text file.

Step 2: Add the _mta-sts DNS TXT record

The DNS record is how senders learn a policy exists and whether it changed. It carries a version tag and an id:

1_mta-sts.yourdomain.com.  3600  IN TXT  "v=STSv1; id=20260628120000Z"

The id is the part people fumble. It's a short string, 1 to 32 alphanumeric characters per Google's requirement, that acts as a version stamp. Senders cache your policy until either max_age expires or the id changes. So every time you edit the policy file, you must change the id, or senders keep using the cached version. The reliable convention is a UTC timestamp like 20260628120000Z. Bump it on every change and you'll never serve a stale policy by accident.

Step 3: Start in testing mode

This is the step that separates a clean rollout from a self-inflicted mail outage. The mode field has three settings, and the difference is the whole game:

In testing mode, supporting senders run every validation check and send you a TLS report when something fails, but they still deliver the message. RFC 8461 describes it as sending a report on policy failures while messages "may be delivered as though there were no MTA-STS validation failure." It's a dry run with full telemetry and zero delivery risk.

Run testing for a couple of weeks. Google's guidance is to set the policy to testing first and "check the daily reports to identify and fix any connection issues" before enforcing. Two weeks of report data is usually enough to catch a forgotten MX host or a certificate problem. If your inbound mail is more complex, give it a month. You're watching for one thing: zero unexpected failures from legitimate senders.

Step 4: Promote to enforce

Once the reports are clean, change two things together. In the policy file, switch mode: testing to mode: enforce. In the DNS record, update the id to a new timestamp so senders re-fetch immediately instead of waiting out the cache.

From that point, a supporting sender that can't make a valid TLS connection to one of your listed MX hosts will refuse to deliver, exactly as intended. RFC 8461 puts it plainly: in enforce mode, sending servers "MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS."

There's a real safety net here worth knowing. MTA-STS only blocks mail when both sides participate and validation fails. Microsoft confirms it: "The only scenario where messages aren't delivered is when both sides are using MTA-STS and MTA-STS validation fails." A sender that doesn't support MTA-STS at all is unaffected and still delivers. So enforce mode raises the floor for the senders who can honor it, without cutting off everyone else.

If something does go wrong after enforcing, the fix is fast: flip the policy file back to testing, bump the id, and you've paused enforcement while keeping the infrastructure in place. Microsoft documents this as the standard incident-mitigation move.

Reading TLS-RPT reports: what the feed tells you

Once TLS-RPT is live, reports start landing daily. They're JSON, and each one summarizes connection attempts to your domain grouped by result. The useful part is the failure types, because each one points at a specific, fixable problem. RFC 8460 defines them; here are the ones you'll actually see.

Reports also carry a policy type for each result, one of tlsa (DANE), sts (MTA-STS), or no-policy-found, as defined in RFC 8460. Most of yours will read sts once your policy is live.

Two of those failure rows deserve special attention during the testing phase. A starttls-not-supported failure usually means you left an MX host out of the policy, and a certificate-host-mismatch often means your MX cert covers the wrong name. Both are exactly the kind of problem you want to catch in testing, before enforce mode would turn them into bounced mail. This is why the staged rollout exists: the report tells you what enforce would break, while nothing is actually breaking yet.

A note on what you won't get from this feed. TLS reports say nothing about authentication, spam complaints, or placement. They're a transport-encryption channel only. For the reputation and complaint signals that decide whether your cold email lands, you still need Postmaster-style monitoring, which the domain health monitoring guide covers.

What this looks like alongside your other DNS records

If you're building out the full authentication-and-DNS stack, sequence matters. MTA-STS and TLS-RPT sit at the end, after the records that actually drive deliverability.

1. SPF, DKIM, DMARC first. These are the deliverability foundation. Without them, transport security is polishing a car with no engine. See the SPF, DKIM, DMARC guide.
2. DMARC to enforcement. Move your DMARC policy from monitoring to p=reject once aggregate reports are clean, a separate staged rollout covered in our DMARC p=reject migration guide.
3. Then MTA-STS and TLS-RPT. Transport encryption on top of a domain that's already authenticating and enforcing.

One structural decision interacts with all of this: whether you send cold email from your root domain or a dedicated subdomain. If you isolate outreach on a sending subdomain, your MTA-STS policy still belongs on the domain that receives mail, which is usually your brand's primary domain where replies land. The subdomain vs root domain guide walks that tradeoff. For the broader picture of how every piece fits, the complete guide to cold email outreach is the hub.

Common questions about MTA-STS and TLS-RPT

Does MTA-STS improve cold email deliverability?

Not directly. It's a transport-encryption and security control, not a reputation or content signal, so it won't change your spam rate or inbox placement. It protects inbound mail to your domain (including replies) and gives you a transport-failure feed via TLS-RPT. Treat it as completeness and security, not as a placement fix.

Can MTA-STS block my legitimate mail?

In enforce mode, yes, if your policy is wrong. A policy that omits a real MX host or points at a host with an invalid certificate can cause supporting senders to refuse delivery. That's the entire reason for the staged rollout: run testing mode, confirm the TLS-RPT reports show no unexpected failures, then enforce. And remember it only blocks when both sides use MTA-STS and validation fails, as Microsoft documents.

Do I need both MTA-STS and TLS-RPT?

You can run TLS-RPT alone, and it's worth doing because it's one zero-risk DNS record that returns useful transport data. Running MTA-STS without TLS-RPT is the combination to avoid, since you'd lose your only visibility into what the policy is doing. The pair is designed to work together: enforce with MTA-STS, observe with TLS-RPT.

How long should I run testing mode before enforcing?

About two weeks for most domains. Google's guidance is to start in testing and read the daily reports until connection issues are resolved. Give complex inbound setups a month. The signal to enforce is simple: a clean run of reports with no failures from legitimate senders.

What's the difference between TLS-RPT and DMARC reports?

They report on different layers. A DMARC aggregate (RUA) report tells you who is sending mail claiming to be your domain and whether it authenticated. A TLS-RPT report tells you whether senders could establish a valid encrypted connection to your domain. Different data, different purpose, both useful. See the DMARC aggregate reports guide for the authentication side.

Is MTA-STS the same as DANE?

No. Both enforce TLS for inbound SMTP, but DANE authenticates via DNSSEC while MTA-STS uses regular certificate authorities and doesn't require DNSSEC, per RFC 8461. MTA-STS is usually the easier first step because most domains don't run DNSSEC. The two can coexist, and a sender that supports both must not let MTA-STS override a failing DANE check.

The bottom line

MTA-STS and TLS-RPT configuration is the transport-encryption layer that sits on top of authentication you've already done. TLS-RPT is one safe DNS record that returns a daily report of how senders' TLS connections to your domain are going. MTA-STS is a policy file plus a DNS record that, in enforce mode, makes participating senders refuse to deliver unless they can encrypt to a valid MX host.

It won't move your placement numbers. It will close a downgrade-attack hole, protect the conversations your campaigns start, and give you a transport-failure feed worth monitoring. Adoption is still under 10% by domain, so doing it puts you ahead of most senders.

The rollout rule is the only one you have to remember: publish TLS-RPT first, run MTA-STS in testing, read the reports, and flip to enforce only when they're clean. Do it in that order and you get the security with none of the risk.

Sources

• IETF, RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• IETF, RFC 8460: SMTP TLS Reporting
• Google Workspace, About MTA-STS and TLS reporting
• Microsoft, Enhancing mail flow with MTA-STS
• Zivver, Use of email security standards in the Netherlands (September 2025)