When mail servers hand messages to each other, they usually try to upgrade the connection with STARTTLS. That encryption is opportunistic: if someone in the path strips the STARTTLS offer or presents a fake certificate, the sending server typically falls back to plain text. Contracts, invoices and personal data can then travel unprotected. MTA-STS closes this gap by telling senders that mail for your domain must be delivered only over encrypted connections with valid certificates, and TLS-RPT sends you reports about failures.
How MTA-STS works
There are two parts: a small DNS TXT record announcing that a policy exists and its current version, and a policy file served over HTTPS listing the accepted MX hosts and the enforcement mode. Senders fetch and cache the policy, then require a valid, name-matching certificate on your MX. Because the policy comes over HTTPS, which is much harder to forge than a DNS answer, MTA-STS does not need DNSSEC and is practical for almost any domain.
Check your MX certificates first
Every MX must present a certificate from a trusted authority, unexpired and matching the MX hostname. Enforcing a policy with a self-signed or mismatched certificate will block your incoming mail.
dig +short MX example.uz
openssl s_client -starttls smtp -connect mail.example.uz:25 -servername mail.example.uz </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesIf your mail is hosted by a provider, confirm the MX name and certificate with them. Some networks block outbound port 25, so run the test from a server if needed.
The policy file
It must be served at https://mta-sts.example.uz/.well-known/mta-sts.txt with a valid certificate:
version: STSv1
mode: testing
mx: mail.example.uz
max_age: 604800testing only reports problems, enforce refuses delivery when requirements are not met, and none withdraws the policy. max_age is in seconds; 604800 is one week. Wildcards such as mx: *.example.uz are allowed. With Nginx, a location = /.well-known/mta-sts.txt block with default_type text/plain is enough; on shared hosting, create mta-sts as a subdomain site and place the file in its .well-known folder.
DNS records
_mta-sts.example.uz. IN TXT "v=STSv1; id=20261104T090000"
_smtp._tls.example.uz. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.uz"
curl -s https://mta-sts.example.uz/.well-known/mta-sts.txt
dig +short TXT _mta-sts.example.uzChange the id every time you edit the policy file; otherwise senders keep using the cached version.
Reading TLS-RPT reports
Supporting providers send daily JSON reports with counts of successful and failed TLS sessions and failure reasons such as expired certificates, name mismatches or missing STARTTLS. Stay in testing until a week or two of reports show no failures, then switch to enforce and bump the id.
Example: an audit firm in Tashkent
A Tashkent audit firm receives financial statements and contracts from clients by email and wants them encrypted in transit. The administrator verifies the MX certificate, creates the mta-sts subdomain, publishes the policy in testing mode and adds both TXT records. Two weeks of TLS-RPT reports show no failures, so the firm moves to enforce, and supporting providers now deliver only over protected connections.
Pitfalls
When changing MX servers, add the new name to the policy and update the id before the move, then wait for caches to expire. Also keep the mta-sts certificate valid, or senders cannot fetch updates. On sayt.uz hosting, free Let's Encrypt certificates for subdomains renew automatically, which covers the mta-sts subdomain.