How to Set Up MTA-STS to Enforce Email TLS Encryption

MTA-STS (Mail Transfer Agent Strict Transport Security) is a protocol that allows domain owners to enforce TLS encryption for incoming email. Without MTA-STS, SMTP connections use opportunistic TLS — meaning a man-in-the-middle attacker can strip the encryption and intercept email in plaintext. This guide walks you through deploying MTA-STS step by step.

Step 1: Create the MTA-STS Policy File

The MTA-STS policy file is a plain text file that declares your TLS requirements. Create a file with the following content:

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

The fields are:

• version — Always STSv1.
• mode — The enforcement mode: testing (report failures but still deliver), enforce (reject messages that cannot use TLS), or none (disable the policy).
• mx — The MX hostnames that the policy applies to. You can list multiple mx: lines and use wildcards. These must match the MX records in your DNS.
• max_age — How long (in seconds) sending servers should cache the policy. Start with 86400 (1 day) during testing, then increase to 604800 (1 week) or higher once you are confident.

Important: Start with mode: testing to receive failure reports without rejecting mail. Only switch to mode: enforce after you have confirmed that all legitimate senders can connect via TLS.

Step 2: Host on the mta-sts Subdomain

The policy file must be served over HTTPS at a specific URL:

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

To set this up:

1. Create a DNS A or CNAME record for mta-sts.yourdomain.com pointing to your web server or static hosting provider.
2. Obtain a valid TLS certificate for mta-sts.yourdomain.com (Let's Encrypt works perfectly for this).
3. Place the policy file at the path /.well-known/mta-sts.txt on the web server.
4. Ensure the file is served with the content type text/plain.

You can use any hosting platform — your existing web server, a static site host like GitHub Pages or Netlify, or a CDN. The only requirements are HTTPS with a valid certificate and the correct URL path.

Step 3: Add the DNS TXT Record

Publish a TXT record at _mta-sts.yourdomain.com to signal that your domain supports MTA-STS. The record format is:

v=STSv1; id=20260317001

The id field is a unique identifier that sending servers use to detect policy changes. Every time you update your MTA-STS policy file, you must also update the id value in this DNS record. A common convention is to use a timestamp or incrementing number.

Sending servers cache the policy based on max_age. When they see a new id in DNS, they re-fetch the policy file. If the id has not changed, they use the cached version.

Step 4: Set Up TLSRPT (TLS Reporting)

TLSRPT is a companion protocol that tells sending servers where to send reports about TLS connection successes and failures. Publish a TXT record at _smtp._tls.yourdomain.com:

v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

You can also specify an HTTPS endpoint for JSON reports:

v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com,https://yourdomain.com/tlsrpt

TLSRPT reports are similar to DMARC aggregate reports but focus on TLS connectivity. They tell you which sending servers attempted TLS connections, whether those connections succeeded, and what errors occurred. This data is invaluable for diagnosing certificate problems, configuration errors, and potential downgrade attacks.

Step 5: Test with MTA-STS Checker

After deploying your policy file and DNS records, use the Email Armory MTA-STS Checker to verify your setup. The checker will validate:

• The _mta-sts DNS TXT record exists and is properly formatted.
• The policy file is accessible at the correct HTTPS URL.
• The policy file syntax is valid and the mode is set correctly.
• The MX hosts listed in the policy match your actual MX records.
• The TLS certificate on the mta-sts subdomain is valid.
• TLSRPT is configured (optional but recommended).

Step 6: Monitor and Move to Enforce

After deploying in testing mode:

1. Monitor TLSRPT reports for 2-4 weeks. Look for any TLS connection failures that indicate compatibility issues.
2. Fix any issues. Common problems include expired certificates on MX servers, mismatched MX hostnames in the policy, or MX servers that do not support TLS.
3. Switch to enforce mode. Update the policy file to mode: enforce and update the id in your DNS TXT record.
4. Increase max_age. Once in enforce mode, increase max_age to 604800 (1 week) or 1209600 (2 weeks) for better protection against DNS-based attacks.
5. Continue monitoring. Keep reviewing TLSRPT reports to catch any new issues as they arise.

Frequently Asked Questions

What is the difference between MTA-STS and DANE?

MTA-STS uses HTTPS to publish its policy and does not require DNSSEC, making it easier to deploy. DANE uses DNSSEC-signed TLSA records in DNS and provides stronger cryptographic guarantees. Both protocols enforce TLS for email in transit, and they can be used together for defense in depth.

Do I need a separate web server for the mta-sts subdomain?

You need to serve the policy file over HTTPS at mta-sts.yourdomain.com, but you do not need a separate server. You can use a subdomain on your existing web server, a static hosting service like GitHub Pages or Netlify, or a CDN. The only requirement is that the URL serves the policy file with a valid TLS certificate.

What is TLSRPT and do I need it?

TLSRPT (TLS Reporting) is a DNS record that tells sending mail servers where to send reports about TLS connection failures. While not strictly required for MTA-STS, it is highly recommended. Without TLSRPT, you will not know when sending servers fail to establish TLS connections with your mail server.

Related Guides

• How to Set Up DMARC
• How to Set Up a BIMI Record
• How to Check an SSL Certificate