How to Set Up MTA-STS: Step-by-Step Guide

24 June 2026 · DMARC Engine · 7 min read

Setting up MTA-STS (RFC 8461, Mail Transfer Agent Strict Transport Security) takes three moving parts that have to agree with each other: a small DNS TXT record, a policy file served over HTTPS, and a CNAME that points the well-known host at where that file lives. This guide walks through each step, gives you a copy-paste worked example, shows how to verify it, and covers the mistakes that catch most people out, including why you should never jump straight to enforce mode.

What MTA-STS actually does (and what it doesn't)

MTA-STS tells sending mail servers, "When you deliver mail to my domain, you must use TLS and you must verify my certificate against this list of MX hostnames." Without it, opportunistic STARTTLS can be silently stripped by an attacker on the path, downgrading your inbound mail to plaintext. MTA-STS closes that gap for senders that support it (Google, Microsoft and Yahoo all do).

A few things to be clear about up front:

MTA-STS protects inbound mail to your domain, the mail other people send to you. It is not a replacement for DMARC, SPF or DKIM, which authenticate mail sent from your domain.
It only works if your inbound mail provider already terminates TLS correctly on your MX hosts. Microsoft 365, Google Workspace and most modern providers do.
The companion record, TLS-RPT (RFC 8460), is separate and optional. It asks senders to email you reports about TLS failures so you can spot problems before flipping to enforce.

The three pieces you need

To publish a working policy you create:

A TXT record at _mta-sts.yourdomain.com announcing that a policy exists and giving it a version ID.
A policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt over valid HTTPS.
A way to host that HTTPS endpoint, usually a CNAME from mta-sts.yourdomain.com to a host that serves the file with a trusted certificate.

1. The DNS announcement record

Publish a TXT record at the _mta-sts subdomain:

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260624T120000"

v=STSv1: the version tag, always this value.
id: an opaque identifier you change every time you publish a new policy file. A timestamp is the convention. When senders see the id change, they re-fetch the policy; if it hasn't changed, they keep using their cached copy.

The id must be 1-32 alphanumeric characters. It is the only signal that tells a sender your policy has moved on, so always bump it when you edit the file.

2. The policy file

Create a plain-text file with exactly this format (LF or CRLF line endings, UTF-8):

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 86400

Line by line:

version: STSv1: required, must be the first line.
mode: is one of testing, enforce, or none. Always start at testing.
mx: is one line per MX hostname permitted to receive your mail. Wildcards (*.example.com) match one label. List every MX hostname your provider uses (for Google Workspace these end in aspmx.l.google.com; for Microsoft 365, yourdomain-com.mail.protection.outlook.com).
max_age: is how long, in seconds, a sender may cache this policy. The spec allows up to 31557600 (one year). Use a short value like 86400 (one day) while testing, then raise it to a week or more once you're confident.

The mx: lines must match the certificate presented by your inbound servers, not just your MX DNS records. With Microsoft 365 and Google Workspace this is handled for you because their MX certificates cover the published hostnames.

3. Hosting the file over HTTPS

The policy must be served from the exact URL https://mta-sts.<yourdomain>/.well-known/mta-sts.txt, and:

It must be HTTPS with a certificate that is valid and trusted for mta-sts.yourdomain.com. A self-signed or expired cert means senders treat the policy as absent.
The mta-sts. host is a subdomain you create specifically for this, and it does not have to be where your mail or main website lives.
Content type should be text/plain. Redirects are not followed for the policy fetch, so serve it directly (a redirect from HTTP to HTTPS on the same host is fine; redirecting the .well-known path itself is not).

Most teams point a CNAME at a static host:

mta-sts.yourdomain.com.  IN  CNAME  hosting.example.net.

Cloudflare Pages, Netlify, GitHub Pages or any static host with automatic TLS all work. The whole "site" is one text file.

Worked example: yourdomain.com on Microsoft 365

Say you receive mail at Microsoft 365 with MX yourdomain-com.mail.protection.outlook.com. Your full set-up:

DNS:

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260624T120000"
mta-sts.yourdomain.com.   IN  CNAME hosting.example.net.
_smtp._tls.yourdomain.com. IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: yourdomain-com.mail.protection.outlook.com
max_age: 86400

That third DNS record is TLS-RPT, covered next.

Turn on TLS-RPT first

Before you even think about enforce mode, publish a TLS-RPT record so you get feedback on whether senders can connect over TLS to your MX:

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

rua=mailto: sends daily JSON reports to that address. You can also use https: to POST reports to an endpoint.
These reports tell you about TLS negotiation and certificate failures, exactly the problems that would cause enforce mode to start rejecting legitimate mail. Read them for at least a couple of weeks of full traffic before tightening.

TLS-RPT works whether your policy is in testing or enforce, and it works even without MTA-STS, so there's no reason not to turn it on early.

Testing mode vs enforce mode

This is the part to get right.

mode: testing: senders honour the policy by reporting failures via TLS-RPT but still deliver the mail even if TLS or certificate validation fails. Zero delivery risk. This is your monitoring phase.
mode: enforce: senders that can't establish verified TLS to a listed MX host will refuse to deliver and defer the message. This is the protection you want, but only once you're sure every listed MX hostname presents a valid certificate and your mx: list is complete.
mode: none tells senders to disregard any cached policy. Use this to cleanly retire MTA-STS (publish none, let caches expire, then remove records).

The safe path mirrors the DMARC enforcement journey: publish in testing, watch TLS-RPT until reports are clean across a full business cycle, then change mode: to enforce, bump the id in the TXT record, and let caches refresh.

Verifying your set-up

Check each piece independently:

The TXT record: confirm _mta-sts.yourdomain.com resolves and shows v=STSv1 with your current id. A DNS propagation delay applies; see how long DNS changes take.
The policy fetch: load https://mta-sts.yourdomain.com/.well-known/mta-sts.txt in a browser. You should see your plain-text policy, served over HTTPS with no certificate warning.
Certificate trust: the cert must be valid for mta-sts.yourdomain.com specifically, not just the apex.
mx alignment: every hostname in mx: should match the certificate your inbound servers actually present.
TLS-RPT: send a test message in and watch for the first daily report; an empty or clean report is the goal.

Our DMARC checker and the wider hosted MTA-STS product surface all of these checks in one place (the TXT record, the policy file, the certificate, the mx: match and incoming TLS-RPT reports) and flag any mismatch before it can cause a deferral.

Common problems

enforce too early. The single biggest cause of MTA-STS outages. Stay in testing until TLS-RPT is clean.
Forgetting to bump id. You edited the policy file but senders still serve the old one because the id didn't change. Always update it.
Certificate doesn't cover mta-sts. A wildcard or apex-only cert that excludes the mta-sts host makes the policy unreadable. Issue a cert for the exact hostname.
Incomplete mx: list. Miss one MX hostname your provider uses and enforce mode will defer mail routed through it. List them all, including provider failover hosts.
HTTP-only or redirected policy. The .well-known/mta-sts.txt path must answer over HTTPS directly. No plain HTTP, no redirect on that path.
Wrong line format. version: STSv1 must be first; keys are lowercase with a colon-space separator.

Next steps

Create the mta-sts. subdomain and host the policy file over HTTPS.
Publish the _mta-sts TXT record in testing mode and a _smtp._tls TLS-RPT record.
Verify all three pieces resolve and load cleanly.
Monitor TLS-RPT for a full business cycle.
Switch mode: to enforce, bump the id, and raise max_age.

MTA-STS rounds out the inbound side of your email security alongside your outbound DMARC, SPF and DKIM records. If you'd rather not hand-manage the DNS, certificate and policy file yourself, hosted MTA-STS keeps the policy, certificate and reporting current automatically and moves you from testing to enforce only when the evidence says it's safe.

How do I set up MTA-STS?