Publishing MTA-STS and TLS-RPT for a custom domain

MTA-STS (RFC 8461) lets a domain tell sending servers to deliver to its mail hosts only over verified TLS, using a certificate that matches the MX name. TLS-RPT (RFC 8460) asks sending servers to report TLS failures to an address you choose. Both are published by the domain owner, so the steps below apply to any custom domain whose DNS you control. If the domain is already hosted with ITProMail, check the current records with dig before you change anything.

Prerequisites

The MX records of the domain must point to the ITProMail mail hosts:

dig +short MX example.com
10 mx1.itpromail.com.
20 mx2.itpromail.com.

You also need a host name for the policy file, mta-sts.example.com, served over HTTPS with a valid certificate for that name.

1. Write the policy file

The policy is a plain text file served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mx1.itpromail.com
mx: mx2.itpromail.com
max_age: 86400

• mode is none, testing or enforce. Start with testing.
• mx lines must list every MX host for the domain. Each MX host name must appear exactly as the MX record shows it.
• max_age is the cache lifetime in seconds. Start with 86400 (one day) and raise it, for example to 604800 (one week), once the policy is stable.

2. Serve the file over HTTPS

Create a DNS A or CNAME record for mta-sts.example.com and serve the file from it. The file must be returned directly, with a 200 response and no redirect. Senders do not follow redirects for this file. Test it:

curl -v https://mta-sts.example.com/.well-known/mta-sts.txt

The response must come from a certificate that is valid for mta-sts.example.com, and the body must match the policy above.

3. Publish the DNS records

_mta-sts.example.com.      IN TXT "v=STSv1; id=20261031T120000"
_smtp._tls.example.com.    IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The id value must change every time the policy changes, because senders only reload a policy when the id differs. Use a short alphanumeric value such as a timestamp. The rua address receives daily TLS reports as mail. Use a mailbox or alias you read. See aliases.

Verify both records:

dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com

4. Roll out in stages

1. Testing. Keep mode: testing for at least two weeks. Senders report failures but still deliver. Read the TLS-RPT reports during this time.
2. Enforce. When the reports show no unexpected failures, set mode: enforce and change the id value. From this point, senders refuse to deliver to a host that cannot provide a valid TLS connection, so a broken certificate causes mail to queue or bounce.
3. Retire. To turn the policy off, publish mode: none with a new id, wait longer than the old max_age, and only then remove the TXT record and the policy file.

Common mistakes

• Changing the policy without changing the id. Senders keep the old version until its max_age expires.
• An MX host missing from the mx: list. In enforce mode, mail to that host is refused.
• Serving the file with a redirect, or with a certificate that does not match mta-sts.example.com.
• Expecting MTA-STS to protect against every attack. It protects the hop between sending server and mail host, and only when senders support it.