MTA-STS and TLS-RPT Setup: Enforce SMTP TLS

Problem

SMTP encryption is opportunistic: if an attacker in the network path strips the STARTTLS offer out of your mail server’s greeting, the sending server can’t tell the difference between “this server doesn’t do TLS” and “someone deleted the offer,” so it delivers your mail in cleartext. MTA-STS closes that hole by publishing a durable promise — my mail servers support TLS with a valid certificate; if you don’t see it, don’t deliver — and TLS-RPT gives you the reports that tell you whether it’s working. The setup is three small pieces that have to agree with each other, and the failure modes are quiet, so this guide is as much about verifying the setup as publishing it.

What you’re publishing

MTA-STS is three things that must line up:

1. A discovery TXT record at _mta-sts.yourdomain — tiny, just v=STSv1; id=<version>. It does nothing except tell senders “I have a policy; here’s its version ID; go fetch the real thing.”
2. A policy file served over HTTPS at the fixed path https://mta-sts.yourdomain/.well-known/mta-sts.txt. This is the actual policy, and it must be delivered over a connection with a valid certificate for the mta-sts. subdomain.
3. A TLS-RPT TXT record at _smtp._tls.yourdomain (a separate standard, RFC 8460) asking senders to email you daily summaries of how TLS negotiation went.

The policy file looks like this:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

mode is the lever: testing (try TLS, deliver anyway, report failures), enforce (refuse delivery if TLS to a listed MX fails), or none (winding it down). mx lists every legitimate mail server — wildcards allowed — so an attacker can’t redirect you to their own. max_age is how long senders cache the policy, in seconds, up to about a year (31557600). MTA-STS has been a published standard since RFC 8461 in 2018, and Gmail began enforcing sender-side MTA-STS in 2019, so a correct policy is honored by a meaningful share of real senders today.

Setup in 4 steps

1. Stand up the policy host first. Create the mta-sts.yourdomain subdomain, get it a valid TLS certificate, and serve the policy file (with mode: testing to start) at /.well-known/mta-sts.txt as text/plain. Verify you can open that exact URL in a browser with no certificate warning — if your browser complains, every sender will fail the fetch too.
2. Publish the discovery TXT. Add _mta-sts.yourdomain TXT "v=STSv1; id=20260627000000". The id is arbitrary but must change whenever the policy file changes; a timestamp is the simplest scheme that always increases.
3. Publish TLS-RPT. Add _smtp._tls.yourdomain TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain". This is what turns the deployment from a guess into a measurement — without it you’re flying blind.
4. Live in testing, then enforce. Leave mode: testing for a couple of weeks and actually read the TLS-RPT reports. They’ll surface any MX that’s missing from your list or has a cert problem. Only once the reports are clean do you change the policy file to mode: enforce and bump the id so senders pick up the new version.

Common setup failures

• The mta-sts. cert is wrong. Expired, self-signed, or doesn’t cover the subdomain. Senders can’t fetch the policy over a trusted connection, so they ignore it entirely. Everything in DNS looks correct; the policy just never applies.
• The mx: list doesn’t match reality. A backup MX you forgot, or a hostname that changed after migration. Harmless in testing; in enforce it bounces mail to the un-listed server.
• You edited the policy but not the id. Senders keep serving the cached old version until max_age expires. The change you made appears to do nothing.
• The policy file is unreachable or at the wrong path. A 404, a redirect, HTTP instead of HTTPS, or the file at the root instead of /.well-known/. The discovery TXT promises a policy the sender can’t retrieve.
• max_age set too long during testing. If you need to roll back, senders cache the policy for the full duration. Keep max_age short (a day or a week) while testing; lengthen it only once you’re confident in enforce.

Diagnose with DechoNet

• Email Check inspects your domain’s mail posture — MX records, transport security signals, and authentication — so you can confirm the mx: hosts in your policy match the MX records the rest of the world sees before you flip to enforce.
• DNS Check lets you verify the two TXT records resolve at their exact names — _mta-sts.yourdomain and _smtp._tls.yourdomain — and that the discovery record carries the id you expect. A missing or stale TXT at either name is the first thing to rule out.

Resolution Checklist

• Open https://mta-sts.yourdomain/.well-known/mta-sts.txt in a browser. It must load over HTTPS with no cert warning and return the policy as plain text.
• Confirm _mta-sts.yourdomain resolves to v=STSv1; id=... and that the id matches the version of the policy you intend to serve.
• Confirm _smtp._tls.yourdomain resolves to a v=TLSRPTv1; rua=... record so you actually receive reports.
• Check every real MX appears in the policy’s mx: list (wildcards count). A backup MX that’s absent will bounce under enforce.
• Stay in mode: testing until TLS-RPT reports come back clean for at least a couple of weeks.
• When you switch to enforce, change the policy file and bump the id in DNS in the same change — otherwise cached senders keep the old mode.

When to Escalate

• If the records and certificate all check out but TLS-RPT reports keep showing failures to a specific MX, the problem is on that mail server: a certificate that doesn’t match its hostname, or a TLS stack that won’t negotiate. Hand it to whoever runs that server — MTA-STS is reporting a real transport problem, not causing one.
• If you can’t create the mta-sts. subdomain or get a certificate for it (managed platform, locked-down DNS), the deployment can’t be completed from your side; the hosting or DNS operator has to provision the subdomain and certificate before any of this applies.