DNSTrustCheck

← All tools  |  Guides

MTA-STS and TLS-RPT Explained: Enforcing Encrypted Mail Delivery

SMTP was designed to fall back to unencrypted delivery if TLS negotiation fails. That means an attacker positioned in the middle of a connection can sometimes strip encryption instead of breaking it outright, a downgrade attack. MTA-STS (Mail Transfer Agent Strict Transport Security) lets your domain declare "only deliver to me over TLS, with a certificate I actually trust," so a downgrade attempt causes delivery to fail loudly instead of silently sending mail in the clear.

Last updated: August 29, 2026

How MTA-STS works

A domain publishes an _mta-sts DNS TXT record containing a version and an id (used to detect policy changes). Senders that see this record then fetch a policy file over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, which lists which MX hosts are covered and the enforcement mode: testing (report problems but still deliver) or enforce (refuse delivery if TLS/certificate checks fail).

Where TLS-RPT fits in

TLS-RPT (SMTP TLS Reporting) is a companion mechanism: a separate _smtp._tls TXT record lists an address to receive aggregate reports about TLS negotiation failures from sending mail systems. It's how you find out a policy is causing legitimate delivery problems before you commit to enforce mode; without it, you're enforcing blind.

Setting it up

  1. Decide which MX hosts should be covered by the policy.
  2. Publish the _mta-sts TXT record with a version and id.
  3. Host the mta-sts.txt policy file at the required HTTPS well-known path, on a certificate that validates cleanly.
  4. Start in testing mode so failures are reported, not enforced.
  5. Set up TLS-RPT to receive and review aggregate failure reports.
  6. Move to enforce once reports come back clean for a reasonable period.
Generate your MTA-STS setup

Generate the _mta-sts and _smtp._tls TXT records plus the mta-sts.txt policy file needed to enforce encrypted inbound mail delivery.

Generate your MTA-STS & TLS-RPT records →

Frequently asked questions

Does MTA-STS replace SPF, DKIM, or DMARC?

No. It addresses a different problem. SPF/DKIM/DMARC authenticate who is allowed to send mail as your domain; MTA-STS protects the transport of mail arriving at your domain, making sure it can't be silently downgraded to an unencrypted connection or intercepted with a fraudulent certificate.

What actually happens in "testing" mode?

Sending systems that support MTA-STS will report TLS failures via TLS-RPT but still attempt delivery even if a check fails; nothing gets blocked. It's meant purely to surface problems with your policy or certificate setup before you switch to enforcement.

Does the policy file really need HTTPS?

Yes. The policy is only trustworthy if it's fetched over a validated HTTPS connection to the specific mta-sts. subdomain at the fixed /.well-known/mta-sts.txt path. A plain-HTTP or self-signed setup defeats the purpose.

Sources