MTA-STS testing vs enforce mode — when is it safe to switch?

Your MTA-STS policy file is live in mode: testing, and you want to know how long to wait — and what to check — before flipping it to mode: enforce, where failing connections start getting dropped instead of just logged.

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

RFC 8461 defines exactly three values for the policy file's mode field: enforce (senders MUST refuse delivery over a connection that fails MTA-STS validation), testing (senders report failures via TLS-RPT but deliver the mail anyway) and none (the domain isn't currently requesting MTA-STS, mainly used to phase out a prior policy). The standard itself doesn't mandate a minimum testing period, but the practical guidance from mailbox providers who support MTA-STS — most visibly Google — is to run testing for roughly two weeks, long enough to collect a full reporting cycle of TLS-RPT data, before moving to enforce. Source: RFC 8461 §3.1 “mode” field (testing / enforce / none) · verified 2026-07-17; operational guidance: Google Workspace Help — Create an MTA-STS policy.

What to do about it

Step 1. Pair MTA-STS testing mode with a live TLS-RPT record (see the setup page above) — without TLS-RPT you're testing blind, with no visibility into what would have failed.
Step 2. Watch for certificate-host-mismatch or starttls-not-supported failures in your TLS-RPT reports during the testing window — those are exactly what enforce mode would start blocking.
Step 3. Give it roughly two weeks minimum, confirming at least one full reporting cycle from every MX host you actually use, before switching mode: testing to mode: enforce.
Step 4. When you do switch, bump the policy file's id field in the same change — mode changes are policy-file edits like any other.

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 →