Mail transport & reputation

What is MTA-STS? SMTP MTA Strict Transport Security explained

MTA-STS forces sending mail servers to deliver email to your domain only encrypted and only to your real mail servers with a valid certificate.

How MTA-STS works

SMTP encrypts via STARTTLS only if both sides offer it – an attacker can suppress that (downgrade). MTA-STS makes encryption mandatory: the domain publishes a policy that sending servers fetch and cache.

It has two parts: a TXT record at _mta-sts.<domain> with an id, and the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. The file contains the mode (enforce, testing or none), the permitted MX hosts and max_age, i.e. how long senders cache the policy.

In enforce mode a message is not delivered unless an encrypted connection with a valid certificate to one of the listed MX hosts succeeds. It is sensible to start with testing plus TLS-RPT reports. Gmail and Microsoft honour MTA-STS.

Example

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

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

max_age 604800 equals one week. After every change to the file, the id in the TXT record must be increased.

Common mistakes

The id is not increased after the policy changes – senders keep using the old one.
An MX host is missing from the policy, for example the new mail server after a move.
The mta-sts subdomain has no valid HTTPS certificate.
A very short max_age (e.g. 86400) – the policy then barely protects.

How the Domain Trust Check rates MTA-STS

Criterion “MTA-STS” (weight 4 of 5): TXT record _mta-sts, policy file via HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt, mode (enforce/testing), syntax, all MX hosts covered and a sensible max_age.

Standard: RFC 8461