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
“Flotek has integrated Palisade into its website and Partner Portal as Flo Verified Mail. The public reporting experience helps businesses identify email-security risks and begin an informed conversation with Flotek.”
Kevin James , Senior Software Developer, Flotek GroupRead the case study →5.0 out of 5 on G2Trusted by over 10,000 domains
More customer stories →
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 shows your team the TLS report evidence (success rate and failure reasons) it needs to decide when to move from testing to enforce. Most vendors just check the policy; Palisade hosts and monitors it.
15-day full-product trial. Nothing is charged until it ends.
Questions readers ask