Skip to main content
Reference Email transport RFC 8461

MTA-STS: SMTP MTA Strict Transport Security

MTA-STS forces sending servers to use TLS when delivering mail to your domain, blocking downgrade attacks that would otherwise let an attacker intercept inbound mail in plaintext.

TL;DR

  • 1 Publish a DNS TXT record + an HTTPS-fetched policy file at mta-sts.<your-domain>.
  • 2 Senders enforce TLS on every connection to your MX hosts.
  • 3 Mode 'enforce' bounces non-TLS delivery; mode 'testing' just reports it.
  • 4 Any paid PhishFence Email Security plan can host the policy file for you, opt-in, with a safe testing-to-enforce ramp.

Watch

Stop email being downgraded to cleartext: enforce TLS with MTA-STS and get daily TLS failure reports with TLS-RPT.

What it does

SMTP is a 1980s protocol that started cleartext; STARTTLS was added later as an opportunistic upgrade, but the sender can't tell the difference between 'this server doesn't speak TLS' and 'an attacker stripped the STARTTLS line.' MTA-STS closes that gap.

When MTA-STS is enabled, sending servers know your MX hosts MUST be reached over TLS with a valid certificate matching the MX hostname. If TLS fails, the message is queued (testing mode) or bounced (enforce mode), but never sent in cleartext.

Combined with TLS-RPT, MTA-STS gives you both prevention (mail won't go cleartext) and visibility (you see TLS failure reports daily).

If you'd rather not manage the policy file and its certificate yourself, any paid PhishFence Email Security plan offers hosted MTA-STS: opt in, CNAME mta-sts.<your-domain> to PhishFence, and we serve the policy file (TLS cert included) on your behalf. Every hosted domain starts in testing mode and only promotes to enforce after a 7-day dwell period with clean TLS-RPT reports, so hosting the file is never the same as switching on enforcement immediately. Repoint the CNAME away at any time and we stop serving; export your policy and self-host whenever you like.

How it works

  1. 1

    Publish a TXT record at _mta-sts.<your-domain> with v=STSv1; id=<unique-id>. The id changes every time you update the policy file.

  2. 2

    Publish the policy file yourself over HTTPS at https://mta-sts.<your-domain>/.well-known/mta-sts.txt with mode, MX hosts, and max_age, or on any paid PhishFence Email Security plan, opt in and CNAME mta-sts.<your-domain> to us and we host the file for you instead.

  3. 3

    Sending servers fetch the policy file once per max_age period, cache it, and enforce it on every subsequent connection to your MX.

  4. 4

    Updating the policy: change the file content, then bump the id in the DNS TXT record so cached copies expire and senders refetch.

Example record

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt Click to select
version: STSv1 mode: enforce mx: smtp.google.com max_age: 604800

Common pitfalls

  • Publishing the DNS TXT but not the policy file (or vice versa). Receivers ignore MTA-STS entirely if either piece is missing.

  • Setting mode: enforce before all your MX hosts have valid TLS. Triple-check certs, hostnames, and SAN matches before flipping.

  • Forgetting to bump the id in the TXT record after updating the policy file. Cached policies stick around for max_age and senders never see the change.

  • max_age too short (e.g. 86400 = 1 day). Adds DNS load and policy churn without much benefit. 604800 (1 week) is the production standard.