Skip to content

Your MTA-STS policy for encrypted mail does not work

Warning Whole domain E-mail delivery

General instructions for every cause. Open this article from your PageCheck report to see only the cause your domain has, filled in with its records.

What it is

MTA-STS has two parts: a TXT record _mta-sts.example.com that announces the policy, and the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt that lists your mail servers. Sending servers read both before they deliver, and keep the file for as long as its max_age says.

What is wrong

The domain announces an MTA-STS policy, but senders cannot use it. Depending on the cause, they deliver without its protection or, when a policy in enforce mode leaves out a mail server, refuse to deliver to it. These are the causes, from the record to the file:

  • There is more than one _mta-sts TXT record. Senders ignore the policy when the record is not unique. Delete the extra records and keep exactly one, "v=STSv1; id=…".
  • The _mta-sts TXT record has no valid id. The record must read "v=STSv1; id=…" with an id of letters and digits only, at most 32 characters.
  • The policy file does not answer. Check that the subdomain mta-sts has a DNS record pointing to the server or Worker that holds the file, and that the server answers on HTTPS.
  • The policy file's certificate is not valid. Senders accept the file only over HTTPS with a valid certificate for the mta-sts subdomain: issue one (Let's Encrypt in the hosting panel; a Cloudflare Worker on a custom domain gets one by itself).
  • The policy address answers with something other than the file. It must answer status 200 with the file itself: no redirect (not even to www or to the main site), no error page.
  • The file is not a valid policy. It needs the lines "version: STSv1", "mode:" testing, enforce or none, at least one "mx:" line (unless the mode is none), and "max_age:" in seconds, at most 31557600.
  • The policy leaves out some of the domain's mail servers. Every mail server (MX) must match an mx line, exactly or with one wildcard label (*.example.com). Senders that enforce the policy refuse to deliver to a server it leaves out.

How to fix

1. Find the cause in the list above and fix it. Open https://mta-sts.example.com/.well-known/mta-sts.txt in a browser: it must show the file as plain text, without a redirect or a certificate warning. A correct file and the records are in the set-up article.

2. Change the id after every change to the file. Senders fetch the file again only when the id in the _mta-sts record changes. Any new value of letters and digits will do.

3. Check it. Open https://mta-sts.example.com/.well-known/mta-sts.txt: it should show the file as plain text. Then run this check again: it reads the file and compares its mx lines with your mail servers. 

Fix the MTA-STS (RFC 8461) set-up of the mail domain example.com: senders cannot use its policy; find out why.
Policy file: https://mta-sts.example.com/.well-known/mta-sts.txt. MX hosts: mail.example.com.

Steps:
1. Make https://mta-sts.example.com/.well-known/mta-sts.txt answer 200 over HTTPS with a valid certificate for mta-sts.example.com, no redirect, with a valid STSv1 policy listing every MX host.
2. If the file changes, change the id in the _mta-sts TXT record (for example to 2).
3. Verify: curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt and dig TXT _mta-sts.example.com +short.
Every MX host must match an mx line exactly or by one wildcard label (*.example.com).

Resources:
- MTA-STS, RFC 8461 (IETF): https://datatracker.ietf.org/doc/html/rfc8461

Check your site to see whether it has this problem. Check a website