How do you publish and test MTA-STS for your domain?

What MTA-STS actually requires

MTA-STS, defined in RFC 8461, lets a domain publish a policy declaring that incoming mail must be delivered over TLS with a valid, matching certificate — and whether a connection that can’t meet that bar should be deferred or rejected. Without it, mail between two TLS-capable servers is usually encrypted only opportunistically, and an attacker in the network path can often force a downgrade to plaintext without either side noticing. Publishing it takes two pieces: a _mta-sts.<domain> DNS TXT record declaring a policy version ID, and an HTTPS-hosted file at https://mta-sts.<domain>/.well-known/mta-sts.txt listing the mode (none, testing or enforce) and the exact MX hostnames the policy covers.

Step 1: confirm your MX hosts resolve correctly

Before writing a policy file, you need the exact, current list of hostnames your domain’s mail actually flows through — a policy that names a mail host you retired months ago will just break delivery once enforced. AdminKit’s MX lookup is live today: it resolves your domain’s MX records and priorities, then checks that up to 5 of the listed hosts actually resolve to an A/AAAA address, so you can see at a glance whether your real mail infrastructure matches what you’re about to write into the MTA-STS policy’s host list.

Step 2: publish the policy

Write the policy file, for example:

version: STSv1
mode: testing
mx: mail.example.com
mx: mail2.example.com
max_age: 86400

Host it at https://mta-sts.<domain>/.well-known/mta-sts.txt over a valid HTTPS certificate — the file itself is only trustworthy if the connection serving it is — and publish the matching DNS TXT record at _mta-sts.<domain> with a policy ID that changes any time you update the file, so sending servers know to re-fetch it.

Step 3: add TLS-RPT for visibility

Publish a TLS-RPT record alongside it, defined in RFC 8460, naming an address to receive aggregate reports of TLS delivery failures:

_smtp._tls.example.com. TXT "v=TLSRPTv1;rua=mailto:[email protected]"

Without this, a strict MTA-STS policy gives you no way to notice a legitimate sender silently failing to deliver — you’d only hear about it if someone complained. TLS-RPT and MTA-STS are normally deployed together for exactly this reason.

Step 4: test before you enforce

Start with mode: testing, which asks compliant sending servers to report what would have happened without actually blocking delivery. Review the TLS-RPT reports for at least one full reporting cycle, confirm every legitimate sending source lines up with the MX list in your policy (re-running the MX lookup above if you change mail providers or add a host), then move to mode: enforce. Manually fetch the policy file (curl https://mta-sts.<domain>/.well-known/mta-sts.txt) to double-check it’s served correctly before relying on it, since a policy file that 404s or serves the wrong content type is silently ignored by some implementations rather than flagged as an error.

What’s still a manual check today

AdminKit’s live mail tools — MX lookup, SPF check and DMARC check — confirm the DNS side of your mail setup, but none of them currently fetch or validate an MTA-STS policy file or open a live TLS connection to one of your MX hosts. Until a dedicated check exists, curl for the policy file and a TLS client against each MX host (openssl s_client -starttls smtp -connect mail.example.com:25) remain the practical way to confirm enforcement is actually working as published. See SPF, DKIM and DMARC explained for how MTA-STS’s transport-security guarantee fits alongside those three, separate mail-authentication layers.

Other exposure checks worth running

If you’re reviewing DNS hygiene more broadly, see is your DNS resolver an open resolver and how to find a dangling CNAME; for a ports-focused check, see how to check if port 123 (NTP) is exposed. This guide sits in AdminKit’s email authentication cluster alongside the live tools and glossary terms that back it.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.