MTA-STS Setup: How to Enforce Encrypted Email Delivery (2026)

Most email marketers know about SPF, DKIM, and DMARC — the three protocols that authenticate who sent an email. Far fewer know about the protocol that protects how that email travels between servers. Without MTA-STS in place, every email your domain sends or receives is vulnerable to a class of interception attack that authentication alone cannot stop.

MTA-STS — Mail Transfer Agent Strict Transport Security — is the standard that forces all email destined for your domain to be delivered over an encrypted TLS connection. It prevents attackers from silently downgrading an encrypted connection to plaintext and intercepting your email in transit. For US businesses handling customer data, financial information, or any sensitive communication by email, MTA-STS is the encryption enforcement layer your authentication stack is missing.

This guide explains exactly what MTA-STS does, how it differs from opportunistic TLS, how to set it up step by step, and how to pair it with TLS-RPT so you receive reports whenever a delivery failure occurs. Keyword difficulty for this topic is low — there is very little good technical content on it — which means publishing a thorough guide here is one of the fastest ranking wins available in the email security space.

What Is MTA-STS and Why Does It Matter?

The Problem: Opportunistic TLS Is Not Enough

When two mail servers exchange email, they use a protocol called SMTP. Since the early 2000s, most SMTP connections support TLS encryption through a mechanism called STARTTLS. In theory, this means email is encrypted in transit. In practice, STARTTLS is opportunistic — if the receiving server does not support encryption, or if an attacker interferes with the TLS negotiation, the sending server silently falls back to sending email in plaintext.

This fallback behaviour is the vulnerability that MTA-STS closes. An attacker positioned between two mail servers — a technique called a man-in-the-middle or SMTP downgrade attack — can strip the STARTTLS offer out of the connection negotiation, causing the sending server to deliver the email in plain, unencrypted text that the attacker can read, copy, or modify.

What MTA-STS Does

MTA-STS lets you publish a policy that tells sending mail servers two things:

1. Always use TLS when delivering email to my domain — do not fall back to plaintext under any circumstances
2. Only accept a valid, trusted TLS certificate — reject connections using self-signed or expired certificates

When a sending mail server looks up your domain before delivering an email, it checks for an MTA-STS policy. If one exists, the server is bound by it. If it cannot establish a verified TLS connection, it must defer delivery and retry — it cannot downgrade to plaintext. This makes email interception attacks against your domain fundamentally impossible as long as the policy is in place.

MTA-STS vs DANE

DANE (DNS-based Authentication of Named Entities) solves the same problem as MTA-STS but requires DNSSEC — a more complex prerequisite that many domains do not have configured. MTA-STS was designed as the practical alternative: it uses HTTPS to host the policy file, which is already universally trusted infrastructure. For most US businesses, MTA-STS is the right choice — DANE is primarily deployed by large ISPs and academic networks.

Who Supports MTA-STS?

As of 2026, MTA-STS is supported by all major mail providers including Gmail, Microsoft 365, Yahoo Mail, Fastmail, and Proton Mail. When these providers send email to your domain, they will check for and honour your MTA-STS policy. Gmail has enforced MTA-STS for inbound mail since 2020 and was the primary driver of industry adoption.

MTA-STS Components: What You Are Setting Up

A complete MTA-STS implementation has three parts:

Each part is required for a complete implementation. The policy file and DNS record work together — the DNS record tells sending servers to look for the policy file; the policy file contains the actual rules.

Step 1: Confirm Your Mail Servers Support TLS

Before publishing an MTA-STS policy, verify that all mail servers listed in your MX records support TLS. If any do not, publishing a strict MTA-STS policy will cause inbound email delivery failures.

How to Check

Run an MX lookup on your domain first:

dig MX yourdomain.com +short

This returns your mail server hostnames (e.g., mail.migomail.com, mx1.migomail.com). Then check each one for TLS support using MXToolbox:

1. Visit mxtoolbox.com/SuperTool.aspx
2. Enter each MX hostname prefixed with smtp: — e.g., smtp:mail.migomail.com
3. Check the result for TLS: Yes and Certificate: Valid

All MX servers must show a valid, non-expired TLS certificate from a trusted CA (Certificate Authority) before you proceed. A self-signed or expired certificate on any MX server will cause MTA-STS enforcement to fail for inbound email.

If you use Migomail's infrastructure for inbound mail, your MX servers are already TLS-configured with valid certificates maintained automatically — no action needed here.

Step 2: Create and Host the MTA-STS Policy File

The MTA-STS policy file is a plain-text file that tells sending servers your TLS requirements. It must be hosted at an HTTPS URL on a specific subdomain — mta-sts.yourdomain.com — which itself requires a valid TLS certificate.

Policy File Format

Create a file named mta-sts.txt with the following content:

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

Field Reference

Understanding the Three Policy Modes

testing mode — Sending servers check the policy and report failures (via TLS-RPT) but still deliver email even if TLS verification fails. This is your starting point — identical in function to DMARC's p=none. Use this for the first 1–4 weeks to confirm no legitimate mail servers are being caught.

enforce mode — Sending servers must establish a verified TLS connection. If they cannot, delivery is deferred and retried but never downgraded to plaintext. This is full protection.

none mode — The policy is withdrawn. Use this if you need to temporarily disable MTA-STS (e.g., during a certificate renewal issue) without removing the DNS record entirely.

Always start with mode: testing. Moving directly to mode: enforce without monitoring first can cause legitimate inbound email to be deferred if any of your MX servers have certificate issues you are not aware of.

Setting the max_age Value

During testing mode, use a short max_age — 86400 (24 hours) or 604800 (7 days) — so that if you need to make changes, cached policies expire quickly. Once in enforce mode and stable, increase to 31557600 (1 year) for efficiency. Longer caching means sending servers check your policy file less frequently, reducing load on your hosting.

Hosting the Policy File

The policy file must be served at exactly:

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

Requirements for the hosting:

• Served over HTTPS only (HTTP is not accepted)
• Valid, trusted TLS certificate on mta-sts.yourdomain.com
• Content-Type header: text/plain
• File is accessible without authentication or redirects
• The subdomain mta-sts.yourdomain.com must exist as a DNS record pointing to the hosting server

Three ways to host it:

Option A — Migomail's MTA-STS hosting service (recommended for non-technical teams) Migomail's MTA-STS hosting service handles the policy file creation, hosting, HTTPS certificate, and automatic renewal in one step. You provide your MX hostnames and policy mode in the dashboard — Migomail generates the correct file, hosts it at the required URL, and keeps the certificate valid. No server configuration required.

Option B — Host on your web server If you manage your own web server (Apache, Nginx, etc.):

1. Create the subdomain mta-sts.yourdomain.com and point it to your server
2. Provision a TLS certificate for mta-sts.yourdomain.com (Let's Encrypt works perfectly)
3. Create the directory path /.well-known/ in the webroot
4. Upload mta-sts.txt to that directory
5. Configure the server to serve it with Content-Type: text/plain

Option C — Host on a CDN / static hosting provider Cloudflare Pages, GitHub Pages, Netlify, and similar platforms all support custom subdomains with automatic TLS. Create a repository with a single file at .well-known/mta-sts.txt, connect your mta-sts.yourdomain.com subdomain to the deployment, and the hosting is handled automatically.

Step 3: Create the MTA-STS DNS TXT Record

The DNS TXT record at _mta-sts.yourdomain.com signals to sending mail servers that your domain has an MTA-STS policy and where to find the version ID. Sending servers use this record to decide whether to fetch the policy file.

Record Format

_mta-sts.yourdomain.com  TXT  "v=STSv1; id=20260425001"

Choosing an id Value

The id value can be any string up to 32 alphanumeric characters. The most practical approach is to use a timestamp in YYYYMMDDNNN format — for example 20260425001 means April 25, 2026, version 1. When you update your policy file (change mode, update MX hostnames, adjust max_age), increment the id to notify sending servers that a new version is available and their cached copy is stale.

Why the id matters: Sending servers cache your MTA-STS policy for up to max_age seconds. If you change the policy file without updating the id, cached servers continue using the old policy until their cache expires — which could be weeks if you have a long max_age. Updating the id forces immediate re-fetching by all servers that check.

Publishing the DNS Record

In your DNS management panel, add:

Step 4: Set Up TLS-RPT (TLS Reporting)

TLS-RPT (SMTP TLS Reporting, RFC 8460) is the reporting companion to MTA-STS. It instructs sending mail servers to send you daily reports whenever a TLS connection to your domain fails — including the failure reason, the affected sending server, and the volume of impacted messages.

TLS-RPT reports are how you know MTA-STS is working and how you catch certificate expiry issues, MX hostname mismatches, or delivery failures before they become significant problems.

TLS-RPT DNS Record Format

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

You can use either a mailto: address or an https: endpoint that accepts JSON POSTs. For most teams, a dedicated email address like tls-reports@yourdomain.com is the simplest option. Migomail's MTA-STS hosting service also accepts TLS-RPT reports and presents them in a parsed, human-readable dashboard — saving you from processing raw JSON files manually.

What TLS-RPT Reports Contain

Each daily report (in JSON format) shows:

• The sending mail server (MTA) that attempted delivery
• The number of successful and failed TLS sessions
• Failure type: starttls-not-supported, certificate-expired, certificate-not-trusted, validation-failure, mta-sts-invalid-policy
• The MX hostname where the failure occurred

During testing mode, review these reports weekly. During enforce mode, set up an alert for any non-zero failure count — failures in enforce mode mean email is being deferred, not delivered.

Step 5: Verify the Complete MTA-STS Setup

Before moving to enforce mode, run a full verification of all three components.

Verify the Policy File Is Accessible

Open a browser and navigate to:

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

You should see the plain text of your policy file with no redirects, no login prompts, and no errors. The URL must load over HTTPS — check that the browser shows a valid padlock.

Verify the DNS Records

Check both DNS records are live:

# MTA-STS record
dig TXT _mta-sts.yourdomain.com +short

# TLS-RPT record
dig TXT _smtp._tls.yourdomain.com +short

Both should return your record values. If either returns empty, the record has not propagated yet — wait 30 minutes and retry.

Use MXToolbox MTA-STS Checker

Visit mxtoolbox.com/mta-sts.aspx, enter your domain, and run the check. The tool validates:

• DNS TXT record exists and is correctly formatted
• Policy file is reachable at the correct HTTPS URL
• Policy file syntax is valid
• All MX hostnames listed in the policy match your actual MX records
• TLS certificates on each MX hostname are valid and trusted

All checks must pass before moving to enforce mode.

Step 6: Move to enforce Mode

After 1–4 weeks of testing mode with clean TLS-RPT reports (zero failures or only failures from known-problematic senders you have investigated), update your policy file to enforce mode.

Updated policy file:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
max_age: 31557600

Changes made:

• mode: testing → mode: enforce
• max_age: 604800 → max_age: 31557600 (1 year — long-term caching once stable)

Then update your DNS TXT record to increment the id:

"v=STSv1; id=20260501001"

The incremented id signals to sending servers that the policy has changed and they must re-fetch the policy file before their next delivery attempt.

What Happens After Moving to enforce

• Sending mail servers that support MTA-STS will require a valid, trusted TLS connection to your MX servers
• If they cannot establish one, they defer delivery and retry — they do not fall back to plaintext
• Your TLS-RPT reports will continue to show any failure events
• Inbound email from servers that do not support MTA-STS at all (rare but possible with legacy systems) continues to be delivered opportunistically — MTA-STS does not break delivery for non-supporting senders, it only upgrades it for supporting ones

MTA-STS and Your Complete Email Security Stack

MTA-STS addresses transport-layer security — how email moves between servers. It complements but does not replace the identity-layer authentication protocols:

A fully hardened email domain in 2026 has all five in place. MTA-STS is typically the last protocol most organisations implement — not because it is the least important, but because SPF, DKIM, and DMARC are prerequisites for compliance and have broader immediate impact on inbox placement. Once authentication is complete, MTA-STS and BIMI represent the final layer of the email security stack.

For the complete authentication setup, read our SPF, DKIM, and DMARC setup guide. For DMARC specifically, our DMARC setup guide covers the full p=none to p=reject progression. And if you are looking to display your brand logo next to emails in Gmail and Apple Mail, the next step after MTA-STS is our BIMI setup guide.

MTA-STS Setup: Complete Checklist

Before you start

• All MX servers confirmed as supporting TLS with valid, trusted certificates
• mta-sts.yourdomain.com subdomain created in DNS
• Hosting provider for policy file identified (Migomail, own server, or CDN)

Policy file

• mta-sts.txt created with correct syntax
• mode: testing for initial deployment
• All MX hostnames listed — one mx: line each, matching MX records exactly
• File hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
• File accessible via HTTPS with no redirects, no auth prompts
• Content-Type header is text/plain

DNS records

• _mta-sts.yourdomain.com TXT record published with v=STSv1; id=[timestamp]
• _smtp._tls.yourdomain.com TXT record published with TLS-RPT rua= address
• Both records verified live via dig or MXToolbox

Verification

• MXToolbox MTA-STS checker returns all-pass for your domain
• Policy file loads correctly in browser at HTTPS URL
• TLS-RPT reports arriving at the configured address

Go to enforce

• 1–4 weeks of testing mode with clean TLS-RPT reports
• Policy file updated: mode: enforce, max_age: 31557600
• DNS id incremented to force policy refresh
• MXToolbox re-verified after changes

Frequently Asked Questions

What is MTA-STS and what does it do? MTA-STS (Mail Transfer Agent Strict Transport Security) is a DNS and HTTPS-based protocol that lets domain owners publish a policy requiring all inbound email to be delivered over an authenticated, encrypted TLS connection. Without MTA-STS, SMTP servers use opportunistic TLS — they attempt encryption but fall back to plaintext if the TLS negotiation fails or is interfered with. MTA-STS removes that fallback, making it impossible for an attacker to intercept email by forcing a downgrade to unencrypted delivery. It protects the transit of email between mail servers, complementing SPF, DKIM, and DMARC which protect email identity and authentication.

Does MTA-STS affect email I send, or only email I receive? MTA-STS protects inbound email delivery to your domain — it governs how other mail servers deliver email to your MX servers. It does not directly govern outgoing email your domain sends. However, when you publish an MTA-STS policy, sending mail servers that support the protocol (including Gmail, Microsoft 365, and Yahoo) will enforce TLS when delivering to your domain. For outbound email, the encryption enforcement depends on the recipient domain's MTA-STS policy — if they have one, your sending mail server will honour it when delivering to them.

Will MTA-STS break any of my existing email delivery? Starting in testing mode carries no delivery risk — it is monitoring-only, identical in function to DMARC p=none. The only delivery risk occurs when moving to enforce mode if any of your MX servers have an invalid or expired TLS certificate, or if your policy file lists incorrect MX hostnames. Sending servers that cannot establish a verified TLS connection in enforce mode will defer delivery rather than fall back to plaintext — email will retry but may be delayed. Running in testing mode and monitoring TLS-RPT reports for 1–4 weeks before enforcing eliminates this risk.

What is TLS-RPT and do I need it? TLS-RPT (SMTP TLS Reporting, RFC 8460) is the reporting protocol that accompanies MTA-STS. It instructs sending mail servers to send you daily JSON reports whenever a TLS delivery failure occurs to your domain. TLS-RPT is not technically required for MTA-STS to function, but it is strongly recommended — without it, you have no visibility into delivery failures caused by certificate issues or policy mismatches. Setting it up requires a single DNS TXT record at _smtp._tls.yourdomain.com with a rua= address. Migomail's MTA-STS hosting service processes TLS-RPT reports automatically and surfaces failures in your dashboard, eliminating the need to parse raw JSON files.

How is MTA-STS different from DMARC? DMARC and MTA-STS solve different problems at different layers. DMARC (with SPF and DKIM) protects email identity — it verifies that an email claiming to come from your domain actually did, and tells receiving servers what to do with emails that fail that check. MTA-STS protects email transit — it ensures that emails delivered to your domain travel over an encrypted channel that cannot be intercepted or downgraded. A domain needs both: DMARC to prevent impersonation and spoofing, and MTA-STS to prevent interception of legitimate email in transit. They operate independently and do not overlap in function.

Summary

MTA-STS closes the encryption gap that SPF, DKIM, and DMARC leave open. While those three protocols verify who sent an email, MTA-STS verifies that the email was delivered securely — over an encrypted, verified TLS connection that cannot be silently stripped by an attacker.

The setup process is straightforward:

1. Confirm all MX servers support TLS with valid certificates
2. Create and host the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
3. Publish the _mta-sts DNS TXT record with a version id
4. Publish the _smtp._tls TLS-RPT DNS record for delivery failure reporting
5. Verify all components with MXToolbox
6. Run in testing mode for 1–4 weeks, review TLS-RPT reports
7. Move to enforce mode and update the max_age to 1 year