MTA-STS: A Complete Setup Guide (with TLS-RPT and DANE context)

Why MTA-STS exists

SMTP was designed before TLS. STARTTLS was bolted on to negotiate TLS mid-conversation, which is elegant but trivially defeatable: an attacker in the middle simply strips the server's 'STARTTLS' capability from the EHLO response, and both MTAs fall back to plaintext. You will never know - the servers don't complain.

MTA-STS (RFC 8461) solves this by letting receiving domains publish a policy that says 'TLS is mandatory, these are my MX hosts, don't accept anything else.' Senders fetch the policy over HTTPS (with Web PKI, not DNSSEC) and refuse to downgrade. Combined with TLS-RPT (RFC 8460), senders also send you a daily report on every TLS failure.

The three components

1. DNS TXT record at _mta-sts.<domain> - signals the policy exists and carries an id.
2. HTTPS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt - the actual policy.
3. TLS-RPT TXT record at _smtp._tls.<domain> - where senders report failures.

Step 1 - Provision the mta-sts subdomain

RFC 8461 requires the policy to live at exactly mta-sts.<domain>, over HTTPS, with a valid certificate the sender's TLS trust chain will accept. You need to stand up the subdomain and host one static file.

Pick the hosting pattern that fits your stack:

• Same webserver as your main site - add a second server block for mta-sts.<domain>.
• Dedicated edge bucket - Cloudflare Pages, Netlify, Vercel, AWS S3+CloudFront, GitHub Pages with a custom domain.
• Dedicated tiny VM - overkill for a single file, but works.

Step 2 - Write the policy file

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

The mx lines must be exact matches for your MX record contents - not CNAME targets, not wildcards unless you genuinely run wildcard MX. max_age is how long senders cache the policy; start at 86400 (one day) so changes propagate quickly during the rollout.

server {
    listen 443 ssl http2;
    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;
        add_header Cache-Control "max-age=300" always;
    }

    # 404 for everything else - the subdomain serves exactly one file.
    location / { return 404; }
}

1. Create a Pages project, add a file at public/.well-known/mta-sts.txt
2. Assign custom domain mta-sts.example.com
3. Cloudflare issues the edge certificate automatically
4. Verify: curl https://mta-sts.example.com/.well-known/mta-sts.txt

Step 3 - Publish the _mta-sts TXT record

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260417T000000Z"

The id is an arbitrary string, but must change every time you change the policy body. Senders cache by id - a new policy body with the old id is ignored. A UTC timestamp (YYYYMMDDTHHMMSSZ) is a widely used convention that prevents collisions and makes change history obvious.

Step 4 - Turn on TLS-RPT

TLS-RPT is the feedback loop. Without it, you have no visibility into whether your policy is actually being honoured or whether TLS is silently failing for some senders.

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

Reports arrive as gzipped JSON attachments (one per sender per day). You can self-host a parser or use a processor (URIports, Postmark, Valimail, Red Sift).

Step 5 - Promote to enforce

After two weeks of testing mode with clean TLS-RPT reports, update the policy body to mode: enforce, bump the id, and re-publish.

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260501T000000Z"

Once in enforce, conformant senders (Gmail, Microsoft 365, iCloud and others) will refuse delivery if your TLS breaks or your MX changes without a corresponding policy update.

Operating in enforce mode

• Every MX change is now a two-step: update the policy first (new id, new mx list), wait at least one cache lifetime (max_age), then change DNS.
• Certificate renewal on MX hosts is now critical. An expired cert under mode: enforce bounces mail.
• Keep max_age reasonable: 604800 (one week) balances freshness against how often senders re-fetch.
• Audit the mta-sts subdomain as carefully as you audit any other public endpoint - a takeover there means an attacker can publish a no-enforcement policy.

MTA-STS vs DANE

DANE (DNS-Based Authentication of Named Entities) pins the TLS certificate of your MX hosts in DNS - TLSA records. It's the older, more cryptographic alternative to MTA-STS, and it requires DNSSEC on your zone to be trustworthy.

• DNSSEC is not optional for DANE; it is the entire trust root.
• DANE is widely used in the EU public sector and some large European ISPs. Global support - Gmail, Microsoft 365 - is limited on the sending side.
• MTA-STS uses Web PKI instead of DNSSEC and is supported by every major consumer mail provider.
• Pragmatic answer: ship MTA-STS + TLS-RPT now. Add DANE later if you have DNSSEC and care about European reach.