MTA-STS Generator

What else this needs besides the record

1. Stand up the mta-sts.yourdomain subdomain and get a certificate for it.
2. Serve the policy file at /.well-known/mta-sts.txt with a text/plain content type.
3. Publish the TXT record at _mta-sts.
4. Set up TLS-RPT so you can see reports about failed connections.

The MX list has to match

Names in the policy are checked against the receiving server's certificate. If the file omits some of your MX records or lists stale names, enforce mode will stop some senders from delivering. Whenever you change mail provider, update the policy before you change the MX records.

What it actually protects against

STARTTLS works by requesting encryption from inside an already open, unencrypted connection. Anything in the middle can simply strip the line where the server offers STARTTLS, and the sender, seeing no support for encryption, delivers the message in the clear. Both ends believe everything is fine: the recipient has TLS configured, the sender genuinely tried. That is a downgrade attack, and it is invisible from either side.

MTA-STS removes the opportunity. The policy is fetched over https and tells the sender this domain must accept mail over TLS with a valid certificate. It cannot be stripped from the connection because it never travels through it. If the certificate name does not match, or the server does not offer TLS, the message is not sent at all.

Three modes and the order to use them

• none — effectively no policy. The value exists so you can retire a published policy properly: deleting the file is not enough, senders keep honouring the old one until max_age expires.
• testing — the sender checks the policy but still delivers on a mismatch and sends you a report. This is always where you start.
• enforce — a mismatch cancels delivery.

A sensible sequence: TLS-RPT first, then testing with a short max_age of a day or two. Read the reports for a week and they show whether every one of your MX hosts passes and whether some backup server was forgotten. Only after a clean week move to enforce and raise max_age to several weeks.

A long max_age cuts both ways. It protects against policy substitution, and it also means senders will remember a mistake for exactly as long. Keep it short until the configuration has settled.

Where this breaks

• The file is not served as text/plain. The server adds text/html or wraps it in a page, and the policy counts as unreadable. One curl -I settles it.
• The certificate on mta-sts.example.com expired. The policy subdomain lives apart from the main site and its renewal gets forgotten. The policy becomes unreachable while, under enforce, senders keep demanding TLS based on the cached copy.
• The id in the TXT record was not changed. Senders re-read the file only when id changes. Editing the policy without bumping the identifier has no effect for weeks.
• A redirect to www. The policy must be served from exactly https://mta-sts.example.com/.well-known/mta-sts.txt, with no redirects.

MTA-STS and DANE

Both solve the same problem by different means. DANE publishes the certificate fingerprint in DNS and requires working DNSSEC, stronger, but DNSSEC is far from universal. MTA-STS needs only ordinary DNS and an https certificate, which is why it can be deployed almost anywhere, almost immediately.

They do not conflict. With both in place, a sender that speaks DANE uses it and everyone else follows the MTA-STS policy; large mail systems typically run both. Starting with MTA-STS makes sense: the barrier is lower and it closes the same primary scenario.