MTA-STS (Mail Transfer Agent Strict Transport Security)

A DNS TXT record at _mta-sts.<domain> announces the policy version. A separate HTTPS-published policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt carries the actual rules.

The HTTPS step is intentional — pulling the policy over TLS is the bootstrap that makes the rest of the protocol meaningful. A network attacker cannot trivially strip both the DNS TXT and the HTTPS fetch.

_mta-sts.yourdomain.com.   TXT   "v=STSv1; id=20260518-01"

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

mode: none — testing only; sending MTAs ignore the policy.

mode: testing — sending MTAs honour the policy and send TLS-RPT failure reports back, but do not actually reject mail that fails the policy.

mode: enforce — sending MTAs MUST reject delivery to a host that fails policy validation (wrong MX, invalid TLS, certificate mismatch).

MTA-STS tells senders what TLS posture to use. TLS-RPT (next entry) tells you when delivery to your inbound mail failed. Publish both together — without TLS-RPT, you have no visibility into who failed to deliver to you and why.

We honour the published policy strictly. A failed TLS validation, an MX not in the policy, or a missing STARTTLS offer all result in delivery rejection — and we surface the rejection in the dashboard with the specific MTA-STS failure reason so the operator can debug it on the receiver side.