Fix "MTA-STS Policy Is Missing: STSFetchResult.NONE" | DMARCguard Skip to main content<br>12 min read Share
“MTA-STS Policy Is Missing: STSFetchResult.NONE” — What It Means and How to Fix It<br>You ran a status check — most likely Mail-in-a-Box’s System Status Checks — and one line came back with a red ✖: MTA-STS policy is missing: STSFetchResult.NONE. Mail still sends. Mail still arrives. So what is actually broken?<br>Short version: nothing is down, but a protection layer you intended to have is not there. This guide decodes the STSFetchResult.NONE token — where the string comes from and what the enum means — then walks a three-stage diagnosis with copy-paste dig, curl, and openssl commands: DNS TXT record, HTTPS policy fetch, TLS certificate chain. If you first want the protocol background, start with what MTA-STS does and why; this post stays on the error.<br>What does “MTA-STS policy is missing: STSFetchResult.NONE” mean?<br>It means the checker queried DNS and HTTPS for your MTA-STS policy and found nothing usable — no _mta-sts. TXT record, no fetchable policy file, or both. The fix is to publish the TXT record and serve https://mta-sts./.well-known/mta-sts.txt over a valid certificate with a direct HTTP 200 response.<br>The token itself is worth decoding, because no other guide does. STSFetchResult is a Python enum from the open-source postfix-mta-sts-resolver library by Vladislav Yarmak. Mail-in-a-Box imports that library in management/status_checks.py and prints its return value verbatim — output.print_error(f"MTA-STS policy is missing: {valid}") — which is how a Python enum’s repr ends up in your admin panel. The library’s GitHub Issue #60 shows the runtime values: NONE = 0 (no policy found at all) and FETCH_ERROR = 2 (a policy was found but could not be fetched or validated). A working policy returns VALID.<br>Only two tools emit this exact string: Mail-in-a-Box and the library’s own mta-sts-query CLI. MXToolbox, Hardenize, and Google’s Workspace checker report the same condition in their own wording. So if you are seeing stsfetchresult.none, you are almost certainly looking at Mail-in-a-Box status checks.<br>One thing this error does not mean: an outage.<br>Key finding Fail open RFC 8461: when no policy is fetchable, senders "MUST continue with delivery as though the domain has not implemented MTA-STS"<br>Source: RFC 8461, IETF (2018) Your mail is not blocked. Senders fall back to opportunistic TLS. What you are missing is downgrade protection — the guarantee that supporting senders refuse to deliver over a stripped or plaintext connection. That is worth fixing, on your schedule, one gate at a time.
The three-gate diagnosis cascade: each gate must pass before the next one matters. Fix the first failing gate. Stage 1 — Is the _mta-sts DNS TXT record resolving?<br>Start at DNS, because every later stage is meaningless until this one passes. A sending server discovers your policy through a single TXT record — the _mta-sts TXT record — and if that record does not resolve, the resolver returns NONE without ever attempting the HTTPS fetch.<br>Check the _mta-sts TXT record bash
# Query the MTA-STS discovery record<br>dig +short txt _mta-sts.example.com
# Expected: exactly one record in this shape (empty output = record missing)<br>"v=STSv1; id=20260728120000"
# Real-world reference (gmail.com, verified 2026-07-28)<br>dig +short txt _mta-sts.gmail.com<br>"v=STSv1; id=20190429T010101;"
You want exactly one v=STSv1; id=... answer. If you get nothing, work through these branches — ordered most common first, and each one is a documented incident, not a hypothetical:<br>The record was never published to your real DNS. After a Mail-in-a-Box install or upgrade, users of external DNS (Cloudflare, registrar DNS) found the box generated the record internally but never wrote it to the authoritative zone. This is the root cause in the 2020 forum thread (6960) that still ranks for this error. Add _mta-sts.yourdomain.com IN TXT "v=STSv1; id=" at your provider.<br>Propagation lag. Mail-in-a-Box zones use a 1,800-second TTL; a freshly added record can take that long to appear everywhere. Cross-check several public resolvers before concluding it is missing.<br>A wildcard TXT record is shadowing the answer. One admin in the same thread traced the failure to a *. TXT record that stopped the _mta-sts query from being answered. Remove the wildcard or re-add it after the MTA-STS records.<br>Stale id after a policy edit. The record exists but senders keep a cached copy. Microsoft’s MTA-STS documentation requires the id value to change to a new unique string on every policy update so senders re-fetch — Google’s checker enforces a 1–32 alphanumeric id as well.<br>One library quirk to know: a local DNS resolver error on the box also returns NONE (Issue #60), so an external validator can pass while your own status check still errors. When in doubt, run the full discovery chain from outside with our MTA-STS checker — it walks DNS, fetch, and certificate in one pass.<br>Gate passed when:...