What is MTA-STS (and TLS-RPT)?

SPF, DKIM and DMARC stop someone impersonating you. They do nothing about whether mail to you travels encrypted. MTA-STS closes that gap. It tells other mail servers to deliver to you only over verified, encrypted TLS, and TLS-RPT tells you when that fails.

The gap MTA-STS closes

When another server sends mail to your domain, it looks up your MX and usually tries TLS encryption. But classic SMTP TLS is opportunistic: if the encrypted connection fails — or an attacker on the network strips it — the sending server quietly falls back to plaintext. That "downgrade" exposes your inbound mail. MTA-STS makes encryption mandatory and authenticated, so a downgrade is refused, not accepted.

How MTA-STS works

It has two pieces:

  • A DNS TXT record at _mta-sts.yourdomain.com that signals a policy exists and carries an id you change whenever the policy changes.
  • A policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, listing your valid MX hosts, the mode, and a max_age.

A sending server fetches the policy over a valid HTTPS certificate, caches it for max_age, and from then on requires authenticated TLS to your MX hosts.

The three modes

  • none — no active policy (used when retiring MTA-STS).
  • testing — honor the policy but still deliver on TLS failure, and report it. Always start here.
  • enforce — refuse delivery if verified TLS can't be established.

TLS-RPT: your visibility

On its own, MTA-STS is silent about problems. TLS-RPT adds a reporting address via a TXT record at _smtp._tls.yourdomain.com (for example v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com). Sending servers then send you daily summaries of successful and failed TLS connections — so you can move from testing to enforce with confidence.

How to deploy it safely

  1. Publish TLS-RPT first and watch a week of reports.
  2. Publish the MTA-STS policy in testing mode (policy file on an HTTPS subdomain, plus the _mta-sts TXT record).
  3. Confirm reports are clean, then switch the policy to enforce and bump the id.
  4. Keep the MX list in the policy current — an out-of-date policy can block legitimate mail.

This is exactly the kind of moving target a managed setup keeps correct over time.

Frequently asked questions

Is MTA-STS the same as TLS?

No. TLS is the encryption itself; most mail servers already try it opportunistically. The problem is that opportunistic TLS can be silently downgraded to plaintext by an attacker. MTA-STS makes encryption mandatory and authenticated for your domain, so a downgrade is refused instead of accepted.

Do I need MTA-STS if I already have DMARC?

Yes — they solve different problems. DMARC stops people sending mail as you. MTA-STS protects mail being sent to you from being intercepted or downgraded in transit. A complete setup includes both, plus TLS-RPT for visibility.

What's the difference between MTA-STS testing and enforce mode?

In testing mode, servers honor your policy but still deliver (and report) if TLS fails, so you can validate safely. In enforce mode, mail that can't be delivered over verified TLS is refused. You start in testing, confirm via TLS-RPT that everything's clean, then switch to enforce.

MTA-STS is part of the managed stack

StopForge's free exposure scan reads your live records and shows exactly where your email authentication stands — what passes, what silently fails, and whether anyone can still send as your domain. No changes to your mail, no obligation.

See if your domain can be spoofed

Related guides: What is DKIM and how does it work? · Can someone send email as your domain? How to check.

← All guides