MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS is a security standard that enforces TLS encryption for email delivery between mail servers.

How MTA-STS Works

The Problem

Email servers communicate using SMTP, which supports optional TLS via STARTTLS. However:

• STARTTLS is opportunistic (optional)
• Attackers can strip STARTTLS (downgrade attack)
• No certificate validation by default
• Man-in-the-middle attacks are possible

The Solution

MTA-STS tells sending servers:

1. TLS is required (not optional)
2. Which mail servers to accept
3. Certificates must be valid

Sender's Server                    Your Mail Server
      │                                  │
      │  1. Look up MTA-STS policy       │
      │     (DNS + HTTPS)                │
      │                                  │
      │  2. Policy says: TLS required    │
      │                                  │
      │  3. Connect with TLS ──────────> │
      │     (or refuse to deliver)       │
      │                                  │

MTA-STS Components

MTA-STS requires two components:

1. DNS TXT Record

Location: _mta-sts.example.com

v=STSv1; id=20240115120000

Field	Description
v	Version (STSv1)
id	Policy ID: up to 32 letters and digits. Change it whenever the policy changes

2. Policy File

Location: https://mta-sts.example.com/.well-known/mta-sts.txt

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

Policy Fields

Field	Required	Description
version	Yes	Always STSv1
mode	Yes	enforce, testing or none
mx	Yes, except in none mode	Allowed MX hosts (one per line)
max_age	Yes	Cache duration in seconds, up to 31557600 (about a year)

Mode

Mode	Behavior
testing	Senders report failures (through TLS-RPT) but still deliver
enforce	Senders refuse to deliver when TLS or certificate validation fails
none	Senders treat the domain as having no MTA-STS policy. Used to retire a policy safely

MX Hosts

List all valid mail servers:

mx: mail.example.com
mx: mail2.example.com
mx: *.mail.example.com

Note: A wildcard matches exactly one label: *.example.com matches mx1.example.com, but not example.com or a.mx1.example.com.

Max Age

How long senders cache the policy:

Duration	Seconds	Use Case
1 day	86400	Testing
1 week	604800	Standard
1 month	2592000	Stable config

Implementation Steps

Step 1: Verify Prerequisites

Before enabling MTA-STS:

• ✅ All MX servers support TLS
• ✅ Valid certificates on all MX servers
• ✅ Certificates match MX hostnames

Step 2: Create Policy File

Create the policy file at:

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

Requirements:

• Must be served over HTTPS
• Valid certificate for mta-sts.example.com
• Content-Type: text/plain
• Accessible publicly
• No redirects: senders don't follow HTTP redirects when fetching the policy

Example:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

Step 3: Add DNS Record

Add TXT record at _mta-sts.example.com:

v=STSv1; id=20240115

The ID should:

• Be unique for each policy version
• Change when policy is updated
• Use only letters and digits, up to 32 characters. A timestamp such as 20240115120000 works well

Step 4: Test

1. Wait for DNS propagation
2. Verify policy is accessible
3. Monitor TLS-RPT reports

Step 5: Enforce

After confirming no issues:

1. Change mode to enforce
2. Update policy ID in DNS
3. Increase max_age

Testing vs. Enforce

Testing Mode

mode: testing

• Senders log failures but deliver anyway
• Use TLS-RPT to see issues
• No impact on email delivery
• Start here

Enforce Mode

mode: enforce

• Senders reject if TLS fails
• Full protection against downgrade attacks
• May block email if misconfigured
• After thorough testing

Common Issues

Policy Not Accessible

Symptoms:

• MTA-STS check fails
• Senders can't fetch policy

Causes:

• Wrong subdomain (mta-sts not www)
• Missing or invalid HTTPS certificate
• Firewall blocking access
• Wrong path (must be /.well-known/mta-sts.txt)
• The server redirects the request, for example to another host or path

Certificate Errors

Symptoms:

• TLS-RPT reports certificate failures

Causes:

• Expired certificate
• Wrong hostname in certificate
• Self-signed certificate (not allowed)
• Certificate chain incomplete

MX Mismatch

Symptoms:

• Delivery failures in enforce mode

Causes:

• Policy MX hosts don't match DNS MX records
• A wildcard that doesn't cover the host (it matches one label only)
• Typos in hostnames

Policy ID Not Updated

Symptoms:

• Policy changes not taking effect

Cause:

• Senders cache based on policy ID
• ID must change when policy changes

Solution:

• Update DNS record with new ID
• Use timestamp-based IDs

Removing MTA-STS

Senders cache your policy for up to max_age, and keep applying a cached enforce policy even after you delete the records. To remove MTA-STS safely:

1. Publish a policy with mode: none and change the id in the TXT record:

   version: STSv1
   mode: none
   mx: mail.example.com
   max_age: 86400

2. Wait at least as long as the old max_age.

3. Remove the _mta-sts TXT record, then the policy file.

MTA-STS and TLS-RPT

MTA-STS works best with TLS-RPT:

1. MTA-STS - Defines the policy
2. TLS-RPT - Reports on policy enforcement

Always configure both:

_mta-sts.example.com   TXT  "v=STSv1; id=20240115"
_smtp._tls.example.com TXT  "v=TLSRPTv1; rua=mailto:tls@example.com"

Hosting Options

Self-Hosted

Run your own web server:

• Full control over infrastructure
• Requires ongoing maintenance
• Need HTTPS certificate management
• Must ensure high availability

MailShield Hosted

On the Pro plan, MailShield can host your MTA-STS policy with just 2 DNS records:

mta-sts.example.com    CNAME   mta-sts.mailshield.app
_mta-sts.example.com   TXT     "v=STSv1; id=YOUR-POLICY-ID"

Benefits:

• No web server needed
• Automatic HTTPS certificates
• High availability infrastructure
• Built-in DNS validation
• Policy ID management
• Checks every 2 hours, with alerts when the policy changes or can't be fetched

Set up MTA-STS Hosting →

CDN/Static Hosting

Use services like:

• Cloudflare Pages
• GitHub Pages
• AWS S3 + CloudFront

Best Practices

Do

✅ Start with mode: testing
✅ Configure TLS-RPT for visibility
✅ Test thoroughly before enforcing
✅ Include all MX hosts in policy \ ✅ Use wildcards carefully \

Don't

❌ Start with mode: enforce
❌ Forget to update policy ID
❌ Use mismatched MX hosts
❌ Skip TLS-RPT configuration
❌ Use very short max_age in production

Example Configurations

Basic Testing

DNS:

_mta-sts.example.com  TXT  "v=STSv1; id=2024011501"

Policy:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

Full Enforcement

DNS:

_mta-sts.example.com  TXT  "v=STSv1; id=2024011502"

Policy:

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

Multiple MX with Wildcards

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