MTA-STS

The policy that stops mail to your domain from silently falling back to plaintext.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain declare over HTTPS that mail delivered to it must use TLS with a valid certificate. Sending servers that honor the policy will refuse to deliver over an unencrypted or unverifiable connection.

Why it matters

SMTP encryption is opportunistic by default: the sender offers STARTTLS, and if a network attacker strips that offer, mail falls back to plaintext with no error anyone sees. MTA-STS closes that downgrade hole using infrastructure everyone already has, HTTPS and its certificate authorities, where the alternative (DANE) requires DNSSEC. Note the direction: publishing a policy protects mail you receive. Your outbound mail is protected when the domains you send to publish policies of their own, which Gmail, Outlook, and Yahoo all do.

In practice

MTA-STS has two parts. A DNS record announces that a policy exists and versions it:

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

The policy itself is a file served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.example.com
max_age: 86400

The id changes whenever the policy changes, so senders know to re-fetch. mode: testing reports failures without blocking delivery; enforce blocks delivery that cannot meet the policy. Start in testing, and pair it with TLS-RPT so failures show up as reports before they can become lost mail.

How Email Fast handles it

For domains hosted on Email Fast, the platform serves the /.well-known/mta-sts.txt policy file on your behalf: you publish one DNS record and the HTTPS side, including the certificate for the mta-sts subdomain, is handled. Domain verification checks the pair alongside SPF, DKIM, and DMARC.