MTA-STS: What It Is and How to Set It Up

MTA-STS (MTA Strict Transport Security, pronounced em-tee-ay ess-tee-ess) is an email standard that forces mail servers to use encrypted TLS connections when delivering mail to your domain. Without it, email can travel through unencrypted SMTP hops where messages can be read, modified, or intercepted.

If you've already set up SPF, DKIM, DMARC, and BIMI, MTA-STS is the next layer. It doesn't stop spoofing — DMARC does that. It stops interception in transit. And as Gmail, Outlook, and Yahoo enforce stricter transport security, having MTA-STS published prevents delivery failures that look like spam problems but are actually routing problems.

How MTA-STS works

Normal email delivery uses SMTP, which negotiates TLS opportunistically. If the receiving server doesn't support TLS, the sending server falls back to plain text — your email travels the internet unencrypted.

MTA-STS changes that by publishing a policy that says: encrypted connections only. The flow:

1. A sending mail server looks up your _mta-sts.example.com DNS TXT record to confirm you have an MTA-STS policy and learn where to fetch it.
2. It fetches the actual policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
3. It checks the policy's expiration and enforces the rules: for a given MX hostname, TLS is mandatory.

If TLS negotiation fails (the receiving server doesn't support it, the certificate is invalid, or the hostname doesn't match), the sending server rejects the message instead of downgrading to plain text. The message bounces with a permanent failure.

What MTA-STS requires

To publish MTA-STS, you need four things:

1. A TLS-enabled MX server — your incoming mail server must support TLS 1.2 or higher on port 25 with a valid certificate matching its hostname. Most hosted email providers (Google Workspace, Microsoft 365, Fastmail, ProtonMail) meet this requirement by default.
2. A DNS TXT record at _mta-sts.example.com — tells senders you have an MTA-STS policy and where to find it.
3. A policy file hosted at a public HTTPS URL — https://mta-sts.example.com/.well-known/mta-sts.txt — with your MX hostnames and enforcement mode.
4. A valid TLS certificate on the server hosting the policy file — the policy is fetched over HTTPS, so your web server needs a working TLS certificate.

Step-by-step MTA-STS setup

Step 1: Know your MX records

Check what mail servers handle your domain. Run:

dig example.com MX +short

You'll see one or more hostnames like:

aspmx.l.google.com.
alt1.aspmx.l.google.com.

These are your MX targets. You'll list them in the policy file.

Step 2: Write the policy file

Create a plain text file with three sections:

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
max_age: 604800

Fields:

• version: STSv1 — always this value.
• mode: — testing logs violations without blocking messages. Start here. enforce blocks unencrypted delivery. none disables the policy (use to turn it off without breaking senders that cached the previous policy).
• mx: — one line per MX hostname. Wildcards (*.example.com) are supported if your MX uses a wildcard.
• max_age: — seconds senders should cache the policy. 604800 (one week) is the minimum; 1209600 (two weeks) is common.

Start in testing mode. This logs policy violations via TLS reporting (TLS-RPT, covered below) without blocking legitimate mail. Once you've confirmed all your mail servers serve valid TLS certificates, switch to enforce.

Step 3: Host the policy file

Upload the policy to your web server:

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

The file must be:

• Served over HTTPS with a valid TLS certificate
• Accessible on port 443 (standard HTTPS)
• Plain text, no HTML wrapper
• Content-Type text/plain is fine; some providers also serve it as text/plain; charset=utf-8

If your web host doesn't let you create a subdomain easily, you can point mta-sts.example.com as a CNAME to your main site and place the file at /.well-known/mta-sts.txt there. Some providers (Cloudflare Pages, Vercel, Netlify) support .well-known paths on custom domains.

Step 4: Add the DNS TXT record

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

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

• v=STSv1 — always this value.
• id= — a version identifier. When you update the policy file, change this ID to a higher value so senders know to re-fetch. A date-based ID (YYYYMMDDNNN) works well.

Step 5: Enable TLS-RPT (TLS Reporting)

TLS-RPT is the companion standard that tells you when MTA-STS enforcement failures happen. Without TLS-RPT, you won't know if mail is being rejected due to your policy.

Add a TXT record at _smtp._tls.example.com:

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

Replace tls-reports@example.com with a mailbox set to receive these reports. The reports are aggregated XML or JSON files sent daily or weekly by major providers (Google, Microsoft, Yahoo) whenever they enforce or fail to enforce your TLS policy.

Step 6: Monitor in testing mode

Leave your policy in testing mode for at least two weeks. During this period, check the TLS-RPT reports for any failures. Common issues:

• A mail server on your MX list doesn't support TLS 1.2
• A certificate has expired or shows a hostname mismatch
• An intermediary MTA added by your provider routes through a non-TLS hop

Fix any issues before switching to enforce.

Step 7: Switch to enforce

Once your TLS-RPT reports show clean results (no failures for at least a week), update the policy file:

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
max_age: 1209600

And update the DNS ID to trigger re-fetch:

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

Does MTA-STS help deliverability?

MTA-STS doesn't directly affect spam filter scoring. But it matters for inbox placement in two important ways:

1. Prevents silent delivery failures. A surprising number of "why did my email bounce" problems trace back to TLS negotiation failures that would have succeeded with MTA-STS. The email never reached the spam folder because it never reached the server at all.
2. Signals domain maturity. Large mailbox providers track how well-maintained a domain is. MTA-STS, alongside a complete set of authentication records (SPF, DKIM, DMARC, BIMI), signals that the domain is actively managed — which is a positive signal in aggregate reputation scoring.

The primary value is security (preventing man-in-the-middle attacks on SMTP) rather than placement. But a professionally maintained domain with all the standards in place will encounter fewer delivery surprises than one with just the basics.

Common MTA-STS mistakes

• Using enforce before testing. If you have a misconfigured MX server, enforce mode causes permanent delivery failures. Always start in testing and review TLS-RPT reports first.
• Missing the .well-known path. The policy must be at /.well-known/mta-sts.txt on the mta-sts subdomain. Putting it elsewhere (e.g., /mta-sts.txt) won't work because the spec mandates the path.
• No TLS-RPT alongside MTA-STS. Without TLS reporting, you're flying blind. Every MTA-STS setup should include a TLS-RPT record.
• Forgetting to update id=. If you change the policy but keep the same DNS TXT record ID, senders that cached the old policy won't know to re-fetch until the max_age expires.

Check your grade free

Don't guess what's broken — see it. Scan your domain free at emailsecuritygrade.com and get an instant A–F grade on your SPF, DKIM, DMARC, and MX records, with a plain-language fix for anything failing. No signup, no install — it runs in your browser.

If your emails are still landing in spam after fixing the records, a deliverability tool like InboxAlly can train mailbox providers to trust your sending — worth a look once your grade is solid.