MTA-STS Explained: How to Enforce TLS Encryption for Your Email

Email Authentication

Standard email encryption (STARTTLS) is opportunistic — servers try to encrypt, but fall back to unencrypted delivery if encryption fails. This makes email vulnerable to downgrade attacks where a network attacker strips the encryption command, forcing plaintext delivery.

MTA-STS fixes this. It's a policy that tells sending servers: "When you deliver email to my domain, you must use TLS. If TLS fails, don't deliver the email at all."

What MTA-STS Does

MTA-STS (Mail Transfer Agent Strict Transport Security) is a DNS and HTTPS-based policy that:

1. Tells sending servers that your domain requires TLS for incoming email
2. Specifies which MX servers are authorized to receive your email
3. Instructs senders to reject delivery if they can't establish a TLS connection
4. Prevents downgrade attacks by making TLS mandatory, not optional

Without MTA-STS, a man-in-the-middle attacker can:

• Strip the STARTTLS command from the SMTP conversation
• Force the connection to use plaintext
• Read or modify the email in transit

With MTA-STS, the sending server knows to always use TLS and to refuse delivery if it can't — even if a network attacker tries to strip encryption.

How MTA-STS Works

MTA-STS requires two components:

1. DNS TXT Record

A TXT record at _mta-sts.yourdomain.com that signals MTA-STS is enabled:

v=STSv1; id=20260301

The id is a version identifier. Change it whenever you update your MTA-STS policy so sending servers know to fetch the new version.

2. HTTPS Policy File

A policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: mail2.yourdomain.com
max_age: 604800

This file specifies:

The Process

When a sender delivers email to your domain:

1. Sender looks up _mta-sts.yourdomain.com TXT record
2. Finds MTA-STS is enabled
3. Fetches the policy from https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
4. Verifies the receiving server matches the MX list in the policy
5. Requires TLS for the connection
6. If TLS fails, the email is not delivered (in enforce mode)

Setting Up MTA-STS

Testing vs Enforce Mode

Start with testing mode. Use TLS-RPT reports to verify there are no TLS connection issues. Once you're confident, switch to enforce.

TLS-RPT: Monitoring TLS Failures

TLS-RPT (TLS Reporting) is a companion protocol that lets you receive reports about TLS failures when servers deliver email to your domain. Set it up alongside MTA-STS:

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

Reports include:

• Which sending servers experienced TLS failures
• What type of failure occurred (certificate error, STARTTLS stripped, negotiation failure)
• How many messages were affected

This is essential during MTA-STS testing and valuable for ongoing monitoring.

Who Should Use MTA-STS?

You Should Consider MTA-STS If:

• You handle sensitive communications (financial, healthcare, legal)
• You're in a regulated industry that requires encryption in transit
• You want to protect against downgrade attacks on incoming email
• You've already implemented SPF, DKIM, and DMARC and want the next security layer

You Can Skip MTA-STS If:

• Your primary concern is deliverability (MTA-STS doesn't directly improve deliverability)
• You don't control your MX servers (e.g., using Google Workspace or Microsoft 365 — they implement MTA-STS on their end)
• You're still working on basic authentication (SPF, DKIM, DMARC) — finish that first

MTA-STS vs DANE

Both MTA-STS and DANE enforce TLS, but they work differently:

For most organizations, MTA-STS is the more practical choice because it doesn't require DNSSEC, which is complex to deploy and maintain.