MTA-STS glossary
What does mode mean in an MTA-STS policy? (enforce vs testing vs none)
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
mode tells sending servers what to do when secure delivery to your domain can't be verified. testing delivers the mail anyway but reports the failure via TLS-RPT; enforce refuses to deliver unless the connection uses valid TLS to an MX matching your policy; none retires the policy. Only enforce actually protects mail in transit.
mode: at a glance | |
|---|---|
| Tag | mode |
| Valid values | testing · enforce · none |
| Default | Required — every MTA-STS policy file must set a mode. |
| Where it goes | One key/value line in the mta-sts.txt policy file, e.g. mode: enforce |
How mode: works
mode is the what-happens-on-failure switch. In testing, a sender that can't negotiate valid TLS to one of your listed MX hosts delivers the message anyway — and, if you've published TLS-RPT, sends you a report describing the failure. Nothing is ever blocked; it's pure monitor mode.
In enforce, that same sender refuses to deliver unless it gets a TLS connection with a valid certificate to an MX matching your policy. This is the only mode that actually stops an attacker from stripping STARTTLS or diverting mail to a rogue MX. none sits at the other end: it tells senders the policy is retired, and is how you decommission MTA-STS cleanly.
The none → testing → enforce ladder is the TLS mirror of DMARC's none → quarantine → reject: monitor first, enforce on evidence. It shares the same failure mode too — domains parked in testing forever, "MTA-STS enabled" on the audit sheet, zero actual protection. Testing is a rollout step, not a destination.
Correct record vs common mistake
Correct
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 1209600Full enforcement — senders refuse to deliver unless they get valid TLS to a listed MX. This is the mode that actually protects mail in transit.
Common mistake
version: STSv1
mode: testing
mx: mail.yourdomain.com
max_age: 86400Fine for a rollout week — but parked here permanently, failures are only reported, never blocked. Testing forever is the MTA-STS version of DMARC p=none forever.
Troubleshooting mode:
| Issue | Likely cause | Fix |
|---|---|---|
| "MTA-STS enabled" but no actual protection | Policy parked at mode: testing long after rollout | Review your TLS-RPT reports; once they're clean, switch to enforce and bump the DNS id |
| Mail delayed after moving to enforce | An MX isn't matched by any mx: line, or its certificate is invalid or expired | Fix the mx pattern or certificate — senders typically retry before bouncing; if the fix will take days, step back to testing first |
| Switched modes but senders behave as before | The id in the _mta-sts DNS record wasn't changed | Bump the id — senders only refetch a cached policy when it changes |
Why it matters for MSPs
Across a managed client base, mode: testing is the checkbox trap. Every domain "has MTA-STS," every audit passes, and not one connection is actually protected — an attacker who can strip STARTTLS can still read your clients' mail in transit. The protection you're selling only exists at enforce.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
DMARC software that does the work
Getting parked in testing is exactly the failure Palisade exists to prevent. Palisade hosts each client's MTA-STS policy, watches the TLS reports, and advances every domain from testing to **enforce** once delivery is proven clean — most vendors just check the policy; Palisade runs it.
1 domain free up to 1,000 emails/month
Questions readers ask