How to set up MTA-STS (policy file + DNS record)

You want to force incoming mail to your domain to use encrypted, certificate-validated TLS — not opportunistic STARTTLS that silently downgrades — but the setup has two separate moving parts that are easy to get half-right.

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

MTA-STS (RFC 8461) needs both pieces published correctly before it does anything: a DNS TXT record at _mta-sts.<yourdomain> with the value v=STSv1; id=<a-short-string>, and a policy file served over HTTPS at exactly https://mta-sts.<yourdomain>/.well-known/mta-sts.txt — note that's a separate mta-sts. hostname, not your bare domain. The policy file declares the mode (enforce, testing or none) and the MX hosts allowed to receive your mail. Any time you change the policy file's contents, the id field in the DNS TXT record must also change — senders cache the policy and only refetch it when they see a new id, so editing the file without bumping id means senders keep using the stale cached version. Source: RFC 8461 §3 “The _mta-sts TXT Record” and §3.1 “Policy File” · verified 2026-07-17.

What to do about it

Step 1. Publish the DNS TXT record first: _mta-sts.yourdomain.comv=STSv1; id=2026071700Z (any string that changes on every update works — a timestamp is the common convention).
Step 2. Host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — this requires a valid TLS certificate for the mta-sts. subdomain itself.
Step 3. Start the policy file with mode: testing while you confirm no legitimate mail gets rejected, then switch to mode: enforce (see the dedicated page below on when that's safe).
Step 4. Every time you edit the policy file, bump the id value in the DNS record in the same change — forgetting this is the most common reason a policy update appears to do nothing.

Frequently asked

Do TLS-RPT and MTA-STS replace DMARC?

No. DMARC authenticates who is allowed to send as your domain; TLS-RPT and MTA-STS protect how mail travels in transit between servers. They're complementary, independent DNS records — not substitutes for each other.

Do I need both TLS-RPT and MTA-STS, or just one?

They work well together but are independent: TLS-RPT is reporting-only (you find out about failures), MTA-STS is enforcement (failing connections get blocked in enforce mode). Most domains set up TLS-RPT first to see what's actually happening before committing to MTA-STS enforce mode.

Will either of these break mail delivery if I get it wrong?

TLS-RPT can't break anything — it's report-only. MTA-STS in enforce mode can, if your policy file lists the wrong MX hosts or your mta-sts. subdomain's certificate is invalid — which is exactly why RFC 8461 and every practical guide recommend a testing-mode period first.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →