MTA-STS Setup: Enforce TLS Encryption for Your Email

What MTA-STS Protects Against

Without MTA-STS, email delivery between servers can be downgraded from encrypted (TLS) to unencrypted (plaintext) by a network attacker. This is called a downgrade attack.

MTA-STS tells senders: "When you deliver email to my domain, you MUST use TLS. If TLS negotiation fails, don't deliver — don't fall back to plaintext."

This protects the content of email in transit to your domain.

Setup (15 Minutes)

Step 1: Create the Policy File

Create a text file with this content:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.mail.protection.outlook.com
max_age: 86400

Fields:

• version: Always STSv1
• mode: Start with testing (report but don't enforce). Change to enforce after verifying.
• mx: Your MX hostnames (one per line). Must match your actual MX records.
• max_age: Cache duration in seconds. 86400 = 1 day for testing. 604800 (1 week) for production.

Step 2: Host the Policy File

The file must be accessible at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Hosting options:

Cloudflare Workers (free): Create a Worker that serves the policy text at the correct path. Bind it to mta-sts.yourdomain.com.

GitHub Pages (free):

1. Create a GitHub repo
2. Add .well-known/mta-sts.txt with your policy
3. Enable GitHub Pages
4. Add CNAME for mta-sts.yourdomain.com → your GitHub Pages URL

Your web server: If you control a web server, create the file at the correct path and point mta-sts.yourdomain.com to it with a valid SSL certificate.

Step 3: Add DNS Records

MTA-STS record:

_mta-sts.yourdomain.com  TXT  v=STSv1; id=20260331

The id is a version string you update whenever the policy changes (forces senders to re-fetch).

A/CNAME record:

mta-sts.yourdomain.com  CNAME  your-hosting-target

(Or A record pointing to your server.)

Step 4: Add TLS-RPT (Optional but Recommended)

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

This tells senders to email you TLS connection failure reports, similar to DMARC RUA reports. Use a dedicated address — these can generate volume.

Step 5: Verify

Use MXToolbox MTA-STS Lookup or sts.dmarcian.com to verify your setup.

Step 6: Advance to Enforce

After 1-2 weeks in testing mode with no issues:

1. Change mode: testing to mode: enforce in the policy file
2. Increase max_age to 604800 (1 week) or higher
3. Update the id in your DNS TXT record (triggers re-fetch)

Why This Matters

MTA-STS is part of the complete email security stack:

Protocol	Protects	Direction
SPF	Sender authorization	Outgoing
DKIM	Message integrity	Outgoing
DMARC	Policy enforcement	Outgoing
MTA-STS	Transport encryption	Incoming
TLS-RPT	Encryption failure reporting	Incoming
BIMI	Brand display	Outgoing

MTA-STS is the only protocol in this stack that protects incoming email to your domain.

Practitioner note: MTA-STS takes 15 minutes to set up with Cloudflare Workers or GitHub Pages. It adds genuine security — not just compliance signaling. As Microsoft moves toward requiring it, setting it up now is forward-looking. It's also a differentiator when clients ask "what makes your email infrastructure more secure?"

Practitioner note: Start in testing mode. If your MX records are misconfigured in the policy (don't match actual MX), enforce mode will cause legitimate email delivery to fail. Testing mode lets you verify without risk.

For background on MTA-STS, see what is MTA-STS. For the complete authentication stack, see the email authentication guide. For DNS configuration details, see the DNS configuration for email guide. If you want the complete email security stack configured (SPF, DKIM, DMARC, MTA-STS, BIMI), schedule a consultation.

Sources

• RFC 8461: MTA-STS
• RFC 8460: TLS-RPT
• Google: MTA-STS Support

---

v1.0 · March 2026