← All articles

Setting up MTA-STS: enforced encryption for incoming email

MTA-STS forces sending servers to deliver your email encrypted only, and only to your real mail servers. Setup with policy file, DNS record and TLS-RPT.

6 min read · Updated 2 September 2026

Between mail servers, encryption is normally only offered, not required — an attacker on the network path can negotiate it away and read along, or redirect emails to a wrong server. MTA-STS (Mail Transfer Agent Strict Transport Security) closes exactly this gap: your domain publishes a binding statement, "deliver to me only over TLS and only to these mail servers". Google, Microsoft and the other big players honour it.

The three building blocks

MTA-STS consists of a policy file at a fixed address, a DNS record that points to it, and — sensibly — TLS-RPT for reports. The policy file ALWAYS lives at the same address: https://mta-sts.your-domain.at/.well-known/mta-sts.txt — which requires a small website on the subdomain mta-sts with a valid certificate.

The policy file itself is plain text and states the mode, the permitted mail servers and the caching period:

First testing, then enforce

In testing mode nothing is rejected yet — senders only report problems (via TLS-RPT). Only enforce makes the rule binding. The safe route: start with testing and a small max_age (e.g. one day), watch the reports for a few weeks, then switch the file to enforce, raise max_age to one week (604800) — and bump the id in the TXT record in the same step.

TLS-RPT: the reports to go with it