What is MTA-STS and how to set it up?

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) is the email equivalent of HTTPS with HSTS: it tells sending mail servers that your domain requires TLS on incoming SMTP connections and specifies exactly which MX hosts are valid. Without MTA-STS, the SMTP protocol falls back to plaintext whenever TLS fails or is attacked — which in 2026 is a completely preventable vulnerability. This guide explains what MTA-STS does, how to publish it, and the common pitfalls.

The problem MTA-STS solves

SMTP was designed in 1982. TLS was retrofitted as STARTTLS, which is opportunistic: sender tries TLS, and if it fails for any reason falls back to plaintext. This is great for compatibility and terrible for security. A man-in-the-middle attacker can:

1. Strip the STARTTLS advertisement from the SMTP banner. The sender sees no TLS available and sends plaintext.
2. Replace the TLS certificate with a self-signed or invalid certificate. Most senders accept it because validation is optional.
3. Downgrade the TLS version or cipher suite, potentially enabling known attacks.

MTA-STS closes all three gaps. A domain with MTA-STS publishes a policy saying "my MX hosts are X and Y, they support TLS 1.2+, and any sender that supports MTA-STS must enforce TLS". Compliant senders (Gmail, Microsoft, Yahoo, and increasingly commercial MTAs) cache this policy and refuse to deliver mail over plaintext or with an invalid certificate.

How MTA-STS works

MTA-STS has three components:

1. A DNS TXT record at _mta-sts.yourdomain:

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

The id is an arbitrary string that you change whenever the policy file changes — this is how senders know to refetch the policy.

2. An HTTPS-served policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The policy file must be served over a valid TLS certificate matching mta-sts.yourdomain.

3. An optional TLS-RPT record at _smtp._tls.yourdomain:

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

TLS-RPT requests daily reports of TLS failures from senders. This is how you find out if your MTA-STS policy is working and whether there are downgrade attempts.

The three modes

MTA-STS has three policy modes:

mode: none — no enforcement. Equivalent to not having MTA-STS. Used only when you need to announce that you are retiring a previously active policy.

mode: testing — senders are told to report failures but not enforce. Use during rollout to catch problems before they block mail.

mode: enforce — senders refuse to deliver when TLS fails or MX hostnames do not match the policy. This is the production mode.

Typical rollout: publish at mode: testing for 14-30 days, monitor TLS-RPT reports, then switch to mode: enforce.

Setting up MTA-STS step by step

Step 1: Inventory your MX hosts. List every MX record on your domain. All of them must be in the policy file. A missing MX in the policy means mail to that MX fails under enforce mode.

Step 2: Confirm TLS on all MX hosts. Connect to each MX host on port 25, issue STARTTLS, verify:

• TLS 1.2 or higher negotiated.
• Certificate hostname matches the MX hostname.
• Certificate chain valid.
• Certificate not expired.

If any MX fails, fix before publishing MTA-STS.

Step 3: Set up the mta-sts subdomain. Add DNS for mta-sts.yourdomain pointing to a web server. Obtain a TLS certificate (Let's Encrypt works fine). Configure HTTPS.

Step 4: Publish the policy file at https://mta-sts.yourdomain/.well-known/mta-sts.txt:

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

Content-Type should be text/plain.

Step 5: Publish the TXT record at _mta-sts.yourdomain:

v=STSv1; id=20250101T000000

Step 6: Publish TLS-RPT at _smtp._tls.yourdomain:

v=TLSRPTv1; rua=mailto:[email protected]

Step 7: Verify. Run a scan on IntoDNS.ai. You want to see:

• _mta-sts TXT record found.
• Policy file fetched successfully over HTTPS with valid certificate.
• All MX hosts listed match actual MX records.
• TLS-RPT record present.

Step 8: Wait and monitor. For 14-30 days in testing mode, watch TLS-RPT reports. These XML/JSON files arrive daily from compliant senders. Look for:

• Certificate validation failures.
• MX mismatch errors.
• TLS version downgrade attempts.
• Unknown senders with TLS issues.

Step 9: Switch to enforce. Update the policy file:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Change the id= in the TXT record to force cache invalidation:

v=STSv1; id=20250115T120000

From this point, compliant senders refuse to deliver mail to your domain over plaintext or with invalid certificates.

What max_age means

max_age is how long (in seconds) a sender caches the policy. Minimum is typically 86400 (1 day), maximum recommended is 31557600 (1 year). A common default is 604800 (1 week).

The trade-off: longer max_age means stronger protection (harder for attackers to force a policy refresh), but also slower rollback if you misconfigure. During initial rollout, use 86400. Once stable, raise to 604800 or more.

Common setup mistakes

Certificate mismatch on mta-sts subdomain. The certificate on mta-sts.yourdomain must be valid for that hostname. A certificate valid for www.yourdomain but not mta-sts.yourdomain causes every policy fetch to fail.

Missing MX in policy file. All active MX records must be in the policy. Miss one and mail to that MX starts bouncing under enforce mode.

id not changed on policy update. Senders cache the policy based on id. If you update the policy file but leave the id unchanged, senders continue using the cached version for up to max_age seconds.

Policy file served with wrong Content-Type. Must be text/plain. Serving as text/html or with a charset parameter breaks parsing at some senders.

Switching to enforce without testing period. If you have an MX misconfiguration, you find out the expensive way.

No TLS-RPT. You have no visibility into whether your policy is working or whether there are downgrade attacks.

Troubleshooting

Policy not cached by senders. Check TXT record syntax, policy file URL reachability, TLS certificate validity on mta-sts.yourdomain. Use IntoDNS.ai to validate the full chain.

Mail from some senders fails under enforce. Those senders may have strict TLS policies. Check their TLS-RPT reports for specific errors. Usually the fix is on your MX TLS configuration.

TLS-RPT reports show frequent failures from one sender. Investigate that sender specifically. Could be a legitimate MTA with an old TLS library or an active downgrade attempt.

Policy file serves over HTTP not HTTPS. Not allowed by MTA-STS spec. Senders will ignore the policy. Configure HTTPS.

Gmail and Yahoo 2026 expectations

As of 2026, Gmail actively downgrades reputation for domains that do not publish MTA-STS. Yahoo and Microsoft signal similar preferences. For any commercial domain, MTA-STS is now effectively mandatory.

When to use IntoDNS.ai

IntoDNS.ai validates the full MTA-STS setup in one scan: TXT record parsing, policy file fetch with TLS certificate validation, MX host comparison, TLS-RPT configuration check. Use it after initial publish, after every policy change, and in weekly monitoring to catch certificate expiry on the mta-sts subdomain.

Hosting the policy file: options

The mta-sts subdomain needs a web server. Options:

1. Dedicated static host. A lightweight static host (AWS S3 + CloudFront, GitHub Pages, Cloudflare Pages, nginx on an existing server) serves the policy file. Smallest ongoing maintenance.

2. Add to an existing web server. If you already run nginx or Apache for your main site, add an mta-sts virtual host and point mta-sts.yourdomain DNS at that server. Reuse existing TLS certificate infrastructure.

3. Cloudflare Worker or Pages Function. For Cloudflare users, a small Worker can serve the policy file without provisioning any infrastructure. Common pattern for domains already on Cloudflare.

The policy file rarely changes, so caching it aggressively is safe. The id= in the TXT record is the cache key, not the file content.

Rollback plan

If an MTA-STS change breaks inbound mail, you have two options:

Option 1: Revert the policy file. Change mode: enforce back to mode: testing or remove a misconfigured MX line. Update id= in the TXT record. Wait for senders to refetch, which takes up to the current cached max_age.

Option 2: Publish mode: none. A policy with mode: none effectively disables MTA-STS. Senders with cached policies honour them until expiry, but they do not enforce new rules.

The catch: senders cache policies for max_age seconds. During a rollback, mail continues to bounce for up to that many seconds at senders that still have the broken policy cached. This is why max_age of 1 week is a good balance — short enough to recover, long enough to provide real protection.

MTA-STS and TLS-RPT together

MTA-STS enforces; TLS-RPT reports. Without TLS-RPT you have no visibility into whether your policy is being honoured or actively attacked. Always publish both. The reports are small (a few KB per day per receiver) and arrive as email attachments in JSON format.

Parsing TLS-RPT reports is easier than DMARC — the format is JSON and the failure types are small in number (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, a handful of others). Alert on anything other than zero.