How to Set Up MTA-STS and TLS-RPT

By default, SMTP encryption is opportunistic — if the TLS handshake fails, mail is often delivered in plaintext anyway, which attackers can exploit with downgrade attacks. MTA-STS (SMTP MTA Strict Transport Security) lets you publish a policy that tells sending servers: "always use TLS with a valid certificate when delivering mail to me, and if you can't, don't deliver." TLS-RPT adds daily reports so you can see when TLS negotiation fails.

What You'll PublishMTA-STS needs three things: a DNS TXT record at _mta-sts, a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and (recommended) a TLS-RPT TXT record at _smtp._tls for reporting.

Step 1 — Publish the MTA-STS DNS Record

This TXT record announces that you have a policy and carries an id that you bump whenever the policy changes (so senders know to refetch it):

Command

_mta-sts.example.com.   IN   TXT   "v=STSv1; id=20260704T120000;"

The id Is a Version StampUse a timestamp like 20260704T120000. Change it every time you edit the policy file — senders cache the policy and only refetch when the id changes.

Step 2 — Host the Policy File over HTTPS

Serve this exact file at https://mta-sts.example.com/.well-known/mta-sts.txt. The host mta-sts.example.com must present a valid, publicly-trusted TLS certificate.

text

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

Field	Meaning
`mode`	`enforce`, `testing`, or `none`
`mx`	Each MX host allowed to receive mail (one line each; wildcards allowed)
`max_age`	How long senders cache the policy, in seconds (604800 = 1 week)

Start in testing ModeDeploy with mode: testing first. In testing mode senders still deliver on TLS failure but send you TLS-RPT reports, so you can catch misconfigured MX certificates before switching to enforce — where failures block delivery.

Step 3 — Add the TLS-RPT Reporting Record

TLS-RPT tells senders where to email aggregate reports about TLS connections to your domain — invaluable for spotting problems before you move to enforce mode:

Command

_smtp._tls.example.com.   IN   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Step 4 — Serve the Subdomain (Nginx example)

nginx

server {
    listen 443 ssl;
    server_name mta-sts.example.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        alias /var/www/mta-sts/mta-sts.txt;
    }
}

Step 5 — Verify

Confirm the DNS record and the policy file both resolve:

bash

# DNS record
dig TXT _mta-sts.example.com +short
# Expected: "v=STSv1; id=20260704T120000;"

# Policy file over HTTPS
curl https://mta-sts.example.com/.well-known/mta-sts.txt

# TLS-RPT record
dig TXT _smtp._tls.example.com +short

You can also confirm everything at once with the ShowDNS Domain Health Report, which checks MTA-STS and TLS-RPT alongside SPF, DKIM and DMARC.

MTA-STS Complements DANEMTA-STS relies on the public CA system, while DANE relies on DNSSEC. They solve the same downgrade problem differently — publishing both gives the widest coverage since not every sender supports each one. See How to Enable DNSSEC if you want to pursue DANE.