# MTA-STS and TLS-RPT explained: how to set them up safely

URL: https://iblockspam.com/blog/mta-sts-tls-rpt-explained
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> What MTA-STS and TLS-RPT protect against, the DNS records and policy file you need, testing vs enforce mode, and safe rollout behind a filtering gateway.

## Short answer

MTA-STS (RFC 8461) tells sending servers to deliver mail to your domain only over TLS, to MX hosts you list, with valid certificates. You publish a _mta-sts TXT record and a policy file on https://mta-sts.yourdomain. TLS-RPT (RFC 8460) adds a _smtp._tls TXT record so senders email you daily reports about TLS failures.

SMTP was designed without encryption. Servers can upgrade a connection with STARTTLS, but by default nothing stops an attacker on the network from stripping that offer or redirecting delivery. MTA-STS lets your domain say "only deliver to these servers, and only over verified TLS". TLS-RPT tells you when that goes wrong. This guide covers both and how to roll them out without losing mail.

## What problem does MTA-STS solve?

When a server sends mail to you, it looks up your MX record and connects. If your server offers STARTTLS, senders usually use it. But that encryption is opportunistic: if the offer disappears, senders typically fall back to plain text, and many don't check that the certificate matches the hostname.

That leaves two attacks open, as described in [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html):

- **Downgrade.** An attacker on the path removes the STARTTLS offer, so mail goes unencrypted and can be read.
- **Redirection.** An attacker spoofs DNS answers so the sender connects to the attacker's server instead of yours.

MTA-STS closes these gaps for senders that support it. Your domain publishes a policy over HTTPS listing the MX hosts that are allowed and saying that TLS with a valid certificate is required. Senders cache that policy and refuse to deliver to anything that doesn't match.

Microsoft says Exchange Online always validates MTA-STS when sending to protected domains ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/security-and-compliance/enhance-mail-flow-using-strict-transport-security)), and Gmail complies with recipient policies in enforce mode ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)). So a policy you publish takes effect for a large share of incoming mail.

### What MTA-STS doesn't do

- It doesn't encrypt mail end to end. It protects server-to-server hops into your domain.
- It doesn't authenticate the sender. That's the job of [SPF, DKIM and DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc).
- It relies on ordinary web certificates (the Web PKI), not DNSSEC. RFC 8461 notes that an attacker who obtains a valid certificate, or blocks policy discovery before a sender has cached your policy, can still get around it.

## What do you need to publish?

MTA-STS needs two things: a DNS record and a policy file. TLS-RPT needs one more DNS record.

| Item | Where | Example |
|---|---|---|
| MTA-STS discovery record | TXT at `_mta-sts.example.com` | `v=STSv1; id=20261009000000Z;` |
| MTA-STS policy file | `https://mta-sts.example.com/.well-known/mta-sts.txt` | See below |
| TLS-RPT record | TXT at `_smtp._tls.example.com` | `v=TLSRPTv1; rua=mailto:tlsrpt@example.com` |

### The DNS record

```
_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261009000000Z;"
```

`v=STSv1` is required. `id` is any short string that you **change every time you change the policy**. Senders check the `id` to decide whether to fetch a new copy. Microsoft suggests a UTC timestamp, which is easy to keep unique.

### The policy file

```
version: STSv1
mode: testing
mx: mx1.filter.example.net
mx: mx2.filter.example.net
max_age: 604800
```

- **version**: always `STSv1`.
- **mode**: `testing`, `enforce` or `none` (explained below).
- **mx**: one line per allowed MX host. A wildcard is allowed only as the whole leftmost label, so `*.example.net` matches `mail.example.net` but not `example.net` itself.
- **max_age**: how long senders may cache the policy, in seconds, up to 31,557,600 (about a year). The RFC expects values "in the range of weeks or greater". 604,800 is one week.

The file must be served over HTTPS at exactly that path, on the `mta-sts` subdomain, with a valid certificate for `mta-sts.example.com`. Senders don't follow redirects and should treat only an HTTP 200 response as valid. RFC 8461 suggests senders allow about a minute for the fetch and a maximum size of 64 KB, so keep the host simple and fast. It should be served as `text/plain`.

Microsoft states that Exchange Online can't host this file for you, so you need a web host, static site service or CDN that can serve the `mta-sts` subdomain with its own certificate.

### The TLS-RPT record

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

`rua` can be a `mailto:` address or an `https:` endpoint, and you can list more than one, separated by commas ([RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html)). Use a mailbox or a report-processing service, not a person's main inbox.

## What's the difference between testing and enforce mode?

| Mode | What senders do on a failure | Reports | When to use it |
|---|---|---|---|
| `testing` | Deliver anyway, as if there were no policy | Yes, via TLS-RPT | First weeks, and during changes |
| `enforce` | Don't deliver to a host that fails (treated as a temporary failure, so they retry) | Yes | Once reports are clean |
| `none` | Treat the domain as having no active policy | No policy failures (TLS-RPT may still report `no-policy-found`) | Removing MTA-STS |

In enforce mode, a sender won't deliver to an MX host that isn't listed in your policy, doesn't offer STARTTLS, or presents an invalid certificate. RFC 8461 treats this as a temporary failure, and the sender checks for an updated policy before giving up. That buys you some time to fix mistakes, but not much.

## What's in a TLS-RPT report?

Reports are JSON, usually gzip-compressed, and cover one UTC day. Each one includes:

- who sent it and the date range,
- the policy the sender found (`sts`, `tlsa` or `no-policy-found`),
- counts of successful and failed sessions,
- details of failures: the result type, the sending IP, the receiving MX host and IP.

The failure types tell you what to fix. Common ones include `starttls-not-supported`, `certificate-host-mismatch`, `certificate-expired`, `certificate-not-trusted`, `sts-policy-fetch-error` and `sts-policy-invalid`. A steady count of successes with no failures is the signal you want before enforcing.

TLS-RPT is useful on its own, even without MTA-STS. With `no-policy-found`, reports still show whether senders could negotiate TLS with your MX hosts.

## How do MTA-STS and a filtering gateway interact?

This is where most mistakes happen. The `mx` lines in your policy must match **the hostnames in your MX records**. If your MX points to a filtering gateway, those are the gateway's hosts, not Microsoft 365's or Google's.

Three things follow:

1. **List the gateway's MX hostnames.** A policy copied from Microsoft's documentation (`*.mail.protection.outlook.com`) is only correct when your MX points directly at Exchange Online. Microsoft's own page says that if your MX points to an intermediary service, you need to check that the service meets MTA-STS requirements and follow its instructions.
2. **The gateway's certificates must match its MX hostnames.** Ask your provider whether its inbound MX hosts present CA-signed certificates valid for those exact names. If they don't, enforce mode will block your mail. Testing mode and TLS-RPT will show this before it hurts.
3. **Update the policy before you change MX.** Senders cache your policy for up to `max_age`. If you switch to a new gateway or back to your mailbox provider without updating the policy first, senders holding the old policy will refuse the new hosts. See the rollout steps below.

The hop from the gateway to your mailbox platform is separate. MTA-STS covers delivery *to your MX*. The connection from the gateway onward is governed by your platform's connector settings, such as requiring TLS on a Microsoft 365 Partner connector or the Google Workspace inbound gateway "Require TLS" option.

## How to roll out MTA-STS and TLS-RPT step by step

1. **Check your MX hosts.** Run the [MX Lookup](https://iblockspam.com/tools/mx-lookup) and write down every MX hostname. Confirm each one supports STARTTLS with a certificate valid for its name. If you use a gateway, ask the provider.
2. **Publish TLS-RPT first.** Add the `_smtp._tls` record and wait a week. Reports will show your current TLS health before any policy exists.
3. **Host the policy file in testing mode.** Use `mode: testing`, list every MX host, and start with a short `max_age` such as one day (86400) while you test.
4. **Publish the `_mta-sts` TXT record** with a new `id`.
5. **Verify.** Open `https://mta-sts.example.com/.well-known/mta-sts.txt` in a browser and confirm it loads with no certificate warning and no redirect. Run the [Email Health Check](https://iblockspam.com/tools/email-health-check) to confirm the DNS record is found. (Our check reads the DNS record; it doesn't fetch the policy file.)
6. **Read reports for two to four weeks.** Look for any failure type. Fix certificate or hostname problems at the source.
7. **Switch to enforce.** Change `mode: enforce`, raise `max_age` to at least a week, and **update the `id`** in the TXT record. Google and Microsoft both recommend this testing-then-enforce order.
8. **Keep monitoring.** Certificate renewals are the most common cause of later failures, both for MX hosts and for the `mta-sts` web host.

### Changing MX providers with MTA-STS in place

1. Add the new provider's MX hostnames to the policy alongside the old ones. Optionally switch to `testing`.
2. Update the `id`. RFC 8461 advises updating the policy file before the TXT record.
3. Wait at least the old `max_age`, so every sender's cached copy includes the new hosts.
4. Change your MX records. Our guide to [changing MX records without losing email](https://iblockspam.com/blog/change-mx-records-without-losing-email) covers the rest of the cut-over.
5. Once the old hosts receive no traffic, remove them from the policy, update the `id`, and return to `enforce`.

### Removing MTA-STS

Don't just delete the records. RFC 8461 suggests publishing `mode: none` with a short `max_age`, updating the `id`, then removing the TXT record and policy host only after every previously served policy has expired.

## How common is MTA-STS?

Still rare. In our [October 2026 scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000), only 5.1% of the 693 domains that receive mail published an MTA-STS record, and 6.3% published TLS-RPT. That makes it a useful hardening step rather than a baseline requirement. Finish SPF, DKIM and [DMARC enforcement](https://iblockspam.com/blog/dmarc-none-to-reject-small-business) first.

## Next steps

- Publish a TLS-RPT record today. It's one TXT record, it can't affect delivery, and it shows how senders reach you.
- List your MX hosts and confirm their certificates with your provider.
- Publish MTA-STS in testing mode, read the reports, then enforce.
- Use the free [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker) to fetch your policy file, match it against your MX hosts and confirm your TLS-RPT record. The [Email Health Check](https://iblockspam.com/tools/email-health-check) shows both alongside SPF, DKIM and DMARC. iBlockSpam [domain monitoring](https://iblockspam.com/features/domain-monitoring) can alert you if your MX records change unexpectedly.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Do I need MTA-STS if I already have SPF, DKIM and DMARC?

They solve different problems. SPF, DKIM and DMARC help receivers check who sent a message. MTA-STS protects the connection when other servers deliver mail to you, so it can't be silently downgraded to plain text or redirected to an impostor server. Most domains should finish DMARC first, then add MTA-STS.

### Can MTA-STS stop my email from arriving?

Yes, in enforce mode. If a sender that supports MTA-STS can't connect to a listed MX host over TLS with a valid certificate, it won't deliver. That's why you start in testing mode, read TLS-RPT reports, and only enforce once they show clean results.

### What should the mx line say if I use a filtering gateway?

It must match the hostnames in your MX records, which are the gateway's hosts, not your mailbox provider's. If your MX points to a filtering service, list that service's MX hostnames, and confirm with the provider that those hosts present certificates valid for those names.

### How often do TLS-RPT reports arrive?

RFC 8460 defines reports covering one full UTC day, sent a few hours after the day ends. In practice you get roughly one report per reporting organization per day, as a gzip-compressed JSON file, from the large providers that support it.

### Is MTA-STS common?

Not yet. In our October 2026 scan of the Tranco top 1,000 domains, only 5.1% of the domains that receive mail published an MTA-STS record and 6.3% published TLS-RPT. Adoption is low even among very large sites.

## Sources

- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html)
- [Microsoft Learn: Enhance mail flow with MTA-STS](https://learn.microsoft.com/en-us/exchange/security-and-compliance/enhance-mail-flow-using-strict-transport-security)
- [Google Workspace Admin Help: About MTA-STS and TLS reporting](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)
- [NIST SP 800-177 Rev. 1: Trustworthy Email](https://csrc.nist.gov/pubs/sp/800/177/r1/final)

## Free tools for this guide

- [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker): Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.

---

Source: iBlockSpam, https://iblockspam.com/blog/mta-sts-tls-rpt-explained (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt