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

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:

• 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), and Gmail complies with recipient policies in enforce mode (Google Workspace Admin Help). 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.
• 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.

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). Use a mailbox or a report-processing service, not a person's main inbox.

What's the difference between testing and enforce mode?

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 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 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 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, 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 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 to fetch your policy file, match it against your MX hosts and confirm your TLS-RPT record. The Email Health Check shows both alongside SPF, DKIM and DMARC. iBlockSpam domain monitoring can alert you if your MX records change unexpectedly.

Browse our other SPF, DKIM and DMARC guides.