MTA-STS: Enforcing TLS for Inbound Email

The Problem: STARTTLS Is Opportunistic

Most email between servers is encrypted with STARTTLS. The sending server connects on port 25 in plaintext, sees a STARTTLS advertisement in the EHLO response, upgrades the connection to TLS, and delivers the message encrypted. This works well when nobody is interfering with the connection.

The problem is the "opportunistic" part. STARTTLS is an offer, not a requirement. If a network attacker sits between the sending and receiving servers, they can strip the STARTTLS line from the EHLO response. The sending server sees no TLS offer, shrugs, and delivers the message in plaintext. The attacker reads every word. This is called a downgrade attack, and it is not theoretical — it has been documented in the wild by network researchers and ISP-level surveillance programs.

The sending server has no way to know that your mail server supports TLS. It only knows what the EHLO response tells it, and that response can be tampered with in transit. There is no out-of-band signal that says "this domain requires TLS."

MTA-STS is that signal.

What MTA-STS Does

MTA-STS (Mail Transfer Agent Strict Transport Security), defined in RFC 8461, lets a domain declare that inbound email must be delivered over TLS with a valid certificate. It has two components:

1. A DNS TXT record at _mta-sts.example.com that signals the policy exists and carries a version identifier
2. An HTTPS-hosted policy file at https://mta-sts.example.com/.well-known/mta-sts.txt that specifies which MX hosts are covered and whether to enforce or just test

The DNS record tells sending servers to look for the policy. The policy file tells them what to enforce. Hosting the policy over HTTPS (with a valid certificate) means the policy itself cannot be tampered with — the HTTPS PKI provides the trust anchor that SMTP lacks.

How MTA-STS Works

When a sending server is about to deliver email to your domain, it follows this sequence:

1. Check for MTA-STS — The sender queries _mta-sts.example.com for a TXT record. If the record exists and contains a valid v=STSv1 value, MTA-STS is active.
2. Fetch the policy — The sender makes an HTTPS GET request to https://mta-sts.example.com/.well-known/mta-sts.txt and reads the policy file.
3. Cache the policy — The sender caches the policy for the duration specified by max_age (in seconds). It does not re-fetch on every delivery.
4. Enforce TLS — When delivering to a listed MX host, the sender requires a valid TLS connection. "Valid" means: TLS 1.2 or higher, certificate issued by a trusted CA, certificate hostname matches the MX host. If TLS negotiation fails, the sender does not fall back to plaintext.

If the policy mode is enforce, delivery fails rather than falling back to plaintext. If the mode is testing, delivery proceeds but the sender generates a TLS-RPT report (if you have published a _smtp._tls TXT record for TLS Reporting).

Setting Up MTA-STS

Step 1: Verify Your MX Hosts Support TLS

Before publishing a policy, confirm that every MX host for your domain serves a valid TLS certificate. Use the mxio SMTP Server Test to check each host on port 25. You need:

• STARTTLS advertised in the EHLO response
• A valid, unexpired certificate from a trusted CA
• Certificate SANs that match the MX hostname

If any MX host fails these checks, fix the certificate issue before deploying MTA-STS. An enforce-mode policy with a broken certificate will cause inbound mail to bounce.

Step 2: Create the Policy File

Create a text file with your policy:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

• version — Always STSv1.
• mode — Start with testing. Switch to enforce after validating with TLS-RPT reports.
• mx — One line per MX host. Wildcards are supported (mx: *.example.com). Every MX host in your DNS must be listed here.
• max_age — How long (in seconds) senders should cache this policy. 86400 is one day, good for testing. Production policies typically use 604800 (one week) to 31557600 (one year).

Step 3: Host the Policy File

The policy must be served at exactly this URL:

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

Requirements:

• The mta-sts subdomain needs a DNS A or CNAME record pointing to a web server
• The web server must serve HTTPS with a valid certificate covering mta-sts.example.com
• The response content type should be text/plain
• The file must be publicly accessible (no authentication, no redirects to a different domain)

Static hosting services (GitHub Pages, Cloudflare Pages, S3 + CloudFront, any CDN) work well for this. The file almost never changes.

Step 4: Publish the DNS TXT Record

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

v=STSv1; id=20260408120000

• v — Always STSv1.
• id — A unique identifier that changes whenever you update the policy file. Sending servers compare the cached id to the DNS id and re-fetch the policy when they differ. Use a timestamp or incrementing number.

Step 5: Add TLS Reporting (Recommended)

Publish a TXT record at _smtp._tls.example.com to receive TLS-RPT reports:

v=TLSRPTv1; rua=mailto:tls-reports@example.com

These reports tell you which sending servers encountered TLS failures when delivering to your domain. In testing mode, this is how you find problems before they cause bounced mail.

Deployment Strategy: Testing Before Enforce

Deploy MTA-STS in two phases:

Phase 1: Testing mode — Set mode: testing in the policy file. Sending servers will attempt TLS as required but will still deliver over plaintext if TLS fails. They will, however, send TLS-RPT reports detailing the failure. Monitor these reports for 2-4 weeks. Common issues that surface: MX hosts with expired certificates, certificate hostname mismatches, MX hosts missing from the policy file.

Phase 2: Enforce mode — Once TLS-RPT reports show clean deliveries (no failures), update the policy file to mode: enforce, increase max_age to a longer duration, and update the id in the DNS TXT record. Now sending servers will refuse to deliver in plaintext — TLS failures result in bounced mail rather than silent downgrades.

Do not skip testing mode. An enforce-mode policy with a certificate problem on one of your MX hosts will bounce legitimate inbound email.

Common Mistakes

MX host not listed in the policy file. If your DNS has mx3.example.com as an MX record but the policy only lists mx1 and mx2, sending servers enforcing MTA-STS will refuse to deliver to mx3. Every MX host must appear in the policy.

Short max_age in production. A max_age of 86400 (one day) means sending servers re-fetch your policy daily. If your web server hosting the policy goes down for a day, senders lose their cached policy and fall back to opportunistic TLS. Use at least 604800 (one week) in production.

Policy file not accessible. The HTTPS endpoint returns a 404, a redirect, or requires authentication. Sending servers treat an inaccessible policy as "no policy" and fall back to opportunistic delivery.

Certificate does not cover the mta-sts subdomain. The web server at mta-sts.example.com needs its own valid certificate (or a wildcard covering *.example.com). A certificate for just example.com and www.example.com will not work.

Forgetting to update the id after policy changes. The DNS id field is how sending servers know the policy has changed. If you update the policy file (add an MX host, change the mode) but leave the same id, cached senders will not re-fetch. Always increment or change the id when the policy file changes.

Using enforce mode without TLS-RPT monitoring. Without TLS-RPT reports, you have no visibility into whether sending servers are encountering TLS failures. You will only discover problems when users report missing emails.

Verifying Your MTA-STS Setup

Use the mxio MTA-STS Checker to verify your configuration. The tool checks:

• The _mta-sts DNS TXT record exists and has valid syntax
• The policy file is accessible at the correct HTTPS URL
• The policy file has valid syntax and a recognized mode
• All MX hosts in your DNS are covered by the policy
• The web server certificate is valid and covers mta-sts.example.com

Run the check after initial deployment and again after any changes to MX records, policy file content, or the id value.

MTA-STS vs. DANE

Both MTA-STS and DANE (RFC 7672) solve the same problem — enforcing TLS for email delivery — but they use different trust models.

MTA-STS is more practical for most organizations because it does not require DNSSEC. DANE is cryptographically stronger because it removes the CA trust dependency, but it requires your entire DNS chain to be DNSSEC-signed — and DNSSEC deployment remains low outside of certain TLDs and regions.

If your DNS provider supports DNSSEC and you have the operational maturity to manage it, DANE provides stronger guarantees. For everyone else, MTA-STS is the right choice today.

Check your MTA-STS configuration