MTA-STS is two files that have to agree.
When senders report "STSFetchResult.None," one of them is missing.
MTA-STS (RFC 8461) tells sending servers to require TLS when they deliver to you.
It lives in two places:
1. A DNS TXT record at _mta-sts. — v=STSv1; id=20260826T120000. The id is just a version stamp.
2. A policy file served over HTTPS at mta-sts./.well-known/mta-sts.txt.
The policy file is four lines
version: STSv1
mode: enforce
mx: mail.
max_age: 604800
mode is the switch: testing reports failures without blocking, enforce refuses non-TLS delivery, none withdraws the policy.
STSFetchResult.None means the sender found your DNS record but couldn't fetch a valid policy.
Three usual causes:
1. the .well-known file isn't there
2. the mta-sts subdomain has no valid HTTPS certificate
3. or the file is served with the wrong content type.
Fastest check: open that URL in a browser. If it doesn't load cleanly for you, it won't load for a sending server either.
One gotcha: when you edit the policy file, bump the id in DNS — or senders keep using the cached copy until max_age expires.
What to do: open your policy URL, confirm it returns plain text over valid HTTPS, then validate the whole setup:
#MTASTS #EmailSecurity