MTA-STS Setup Guide: Enforce TLS for Email Transport

Mail Transfer Agent Strict Transport Security (MTA-STS) addresses a critical vulnerability in email transport. SMTP encryption has traditionally been optional, allowing downgrade attacks.

MTA-STS lets you declare that your mail servers require TLS. Sending servers must refuse delivery over unencrypted connections.

What is MTA-STS?

MTA-STS (RFC 8461) enables domain owners to enforce TLS encryption for incoming email. Unlike opportunistic TLS, it prevents fallback to plaintext.

How MTA-STS Works

MTA-STS uses two components:

1. DNS TXT Record - Indicates MTA-STS is enabled
2. Policy File - Specifies enforcement details

DNS Record:

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

Policy File Location:

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

Policy File Format

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

Policy Modes

Why Implement MTA-STS?

MTA-STS addresses the SMTP downgrade attack and other security gaps.

Preventing Downgrade Attacks

In a typical attack:

1. Attacker intercepts SMTP connection
2. Removes STARTTLS from server response
3. Sending server believes encryption unavailable
4. Email transmitted in plaintext
5. Attacker reads or modifies message

Handling Legitimate Failures

Opportunistic TLS fails silently in legitimate scenarios:

• Misconfigured servers
• Expired certificates
• Network issues

MTA-STS ensures failures result in delivery abort, not security compromise.

Mail Server Verification

MTA-STS specifies which servers can receive your mail:

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

This adds protection against DNS spoofing attacks.

Major Provider Support

Google, Microsoft, and Yahoo support MTA-STS. Implementing it ensures maximum protection with these providers.

How to Configure MTA-STS

MTA-STS requires both DNS and web hosting configuration.

Step 1: Create the Policy File

Create a text file with your policy:

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

Important requirements:

• List all MX hosts exactly as they appear in DNS
• Use max_age in seconds (86400 = 24 hours)
• File must be plain text

Step 2: Host the Policy File

Host the file at the exact path:

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

Requirements:

• Valid HTTPS certificate for mta-sts.example.com
• Publicly accessible
• Correct MIME type (text/plain)

Hosting options:

• Your existing web server
• Static hosting (GitHub Pages, Cloudflare Pages)
• Cloud storage with custom domain

Step 3: Create DNS Records

Add the MTA-STS DNS record:

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

The id field:

• Must change whenever policy changes
• Triggers senders to fetch updated policy
• Use timestamp or sequential version

Step 4: Implement TLS Reporting (Optional but Recommended)

Add SMTP TLS Reporting (RFC 8460) to receive failure reports:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Sample TLS report:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2025-01-17T00:00:00Z",
    "end-datetime": "2025-01-17T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 1000,
      "total-failure-session-count": 5
    }
  }]
}

Step 5: Verify Configuration

Test your setup:

# Check DNS record
dig +short TXT _mta-sts.example.com

# Check policy file
curl https://mta-sts.example.com/.well-known/mta-sts.txt

Use online validators:

• mxtoolbox.com/mta-sts.aspx
• hardenize.com

MTA-STS Best Practices

Follow these practices for successful implementation.

Start with Testing Mode

Gather data before enforcing:

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

Monitor TLS reports for connection failures.

Ensure Valid Certificates

Certificate requirements:

• Valid (not expired)
• Trusted CA (not self-signed)
• Matches hostname
• Proper chain configured

Use Appropriate max_age

Short values during testing allow quick policy updates.

Update ID on Policy Changes

Always increment the DNS id when changing policy:

# Before change
_mta-sts.example.com. IN TXT "v=STSv1; id=20250117001"

# After change
_mta-sts.example.com. IN TXT "v=STSv1; id=20250118001"

Senders cache policies. Without ID change, they won't fetch updates.

Coordinate with Maintenance

If disabling TLS for maintenance:

1. Update policy to mode: none
2. Wait for max_age to expire (or use short max_age in advance)
3. Perform maintenance
4. Re-enable policy

Monitor TLS Reports

Review reports for:

• Connection failure patterns
• Certificate problems
• Potential attack attempts
• Misconfigured sending servers

Conclusion

MTA-STS represents an important evolution in email transport security. It closes the gap left by opportunistic TLS encryption.

By declaring TLS requirements and specifying authorized mail servers, you protect against downgrade attacks and DNS spoofing.

Key takeaways:

• Start with testing mode
• Monitor TLS reports carefully
• Ensure certificates are always valid
• Update DNS ID when changing policy

Implementing MTA-STS positions your organization at the forefront of email security.