MTA-STS Configuration Guide

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain declare that sending mail servers must use authenticated TLS when delivering mail to it. It solves a long-standing weakness in SMTP: STARTTLS, the opportunistic encryption SMTP uses, is trivially defeated by a man-in-the-middle. An attacker on the path can strip the STARTTLS advertisement, causing the sender to silently fall back to plaintext, or present an invalid certificate that opportunistic SMTP accepts anyway.

MTA-STS removes that opportunism. Once a sender has fetched and cached your policy, it will refuse to deliver mail over a downgraded or untrusted connection. It applies to inbound mail to your domain — you publish a policy so that other servers protect mail they send to you. MTA-STS pairs naturally with TLS-RPT, which gives you reports when delivery to you fails TLS.

MTA-STS deliberately splits its trust across DNS and HTTPS so that an attacker would have to compromise both:

1. The sender looks up the _mta-sts TXT record to learn that you have a policy and to read its id. 2. If the id is new (or no policy is cached), the sender fetches the policy file over HTTPS from mta-sts.<yourdomain>/.well-known/mta-sts.txt. The HTTPS certificate must be valid and trusted — this is the trust anchor, not DNSSEC. 3. The sender caches the policy for up to max_age seconds. 4. On each delivery, the sender checks that the MX host matches a pattern in the policy, that STARTTLS is offered, and that the MX presents a valid certificate matching the MX hostname. If mode is enforce and any check fails, delivery is refused rather than downgraded.

The cached policy is what makes MTA-STS resistant to active attackers: an on-path attacker cannot strip a policy the sender already has.

A working MTA-STS deployment is exactly two things that must agree with each other:

1. DNS TXT record at _mta-sts.yourdomain.com — announces the policy and carries the id. 2. Policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt — the actual rules.

The mta-sts host needs a publicly trusted TLS certificate. The policy file must list MX patterns that exactly cover your real MX records.

Add a TXT record at _mta-sts.yourdomain.com announcing the current policy version:

Create the policy file and serve it at the exact well-known path over HTTPS, with Content-Type: text/plain:

The policy file is a small set of newline-separated key: value lines:

Start in testing mode. In testing, senders perform every MTA-STS check and report failures via TLS-RPT, but mail is still delivered — so you learn whether your MX coverage and certificates are correct without risking a single message.

After a week or two of clean TLS-RPT reports, switch mode to enforce and bump the id. From then on, senders that have your policy cached will refuse to downgrade. Begin with a shorter max_age (e.g. 86400) during testing so corrections propagate quickly, then raise it for production.

TLS Reporting (TLS-RPT, RFC 8460) is what makes MTA-STS observable. Publish a separate TXT record and senders will email you daily JSON summaries of successful and failed TLS sessions to your domain — including the reason for each MTA-STS or DANE failure:

Confirm the DNS record and the HTTPS policy file agree, the MX patterns cover your real MX, and the id is current with our free MTA-STS Checker, and build a correct record and policy file with the MTA-STS Policy Generator.

Common pitfalls to check: the policy file not reachable over HTTPS (wrong host, bad certificate, redirect instead of a direct 200), the id not changing after a policy edit (senders never re-fetch), and mx: patterns that miss one of your MX hosts. MTA-STS protects transport encryption; combine it with SPF, DKIM, and DMARC for end-to-end email security.