MTA-STS and TLS-RPT briefly explained
MTA-STS and TLS-RPT are two settings for your domain that deal with the encryption of mail coming in to you. You'll come across them in tests like internet.nl or in a report from a security scan. In this article you'll read what they do, what they look like, and whether you need them. Short answer upfront: for most customers it's not necessary.
What problem does it solve?
When a mail server delivers mail to the recipient's mail server, they encrypt the connection if possible (STARTTLS). If that doesn't work, the mail usually just goes unencrypted. The certificate of the receiving server is also often not strictly checked. Someone who can intercept the traffic along the way can disable the encryption this way or redirect the mail to their own server.
With MTA-STS, you let others know as the recipient: mail to my domain must always be encrypted, and only to these mail servers with a valid certificate. A sender that supports MTA-STS will comply with this.
The two parts of MTA-STS
1. A TXT record on the name _mta-sts, which states that a policy exists:
_mta-sts.yourdomain.nl. TXT "v=STSv1; id=20261108T120000;"
The id is a version number that you choose yourself. If you change the policy, also change the id, so that senders fetch the new policy.
2. A policy file at exactly this address, via https with a valid certificate:
https://mta-sts.yourdomain.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Line | Meaning |
|---|---|
mode: testing | Senders deliver as usual, but report problems via TLS-RPT. This is where you start. |
mode: enforce | Senders only deliver via an encrypted connection with a valid certificate, to one of the listed mail servers. If that's not possible, the mail stays queued at the sender. |
mode: none | There is no (more) policy. |
mx: | The name of your mail server, exactly as in your MX record. If you have multiple MX records, put each name on its own line. With a WebOké package, this is usually the server name of your package, as in the example; our mail server's certificate is issued for that name. If your MX points to your own domain name, the certificate might not match, and you shouldn't use enforce. |
max_age: | How long a sender may remember the policy, in seconds. 604800 is one week. |
A sender remembers the policy. As a result, MTA-STS doesn't protect the very first time a sender mails you, but it does afterwards.
TLS-RPT: reports on encryption
With TLS-RPT you ask senders for a daily report on failed encryption, for example due to an expired certificate or a mail server name that isn't in your policy. It's one TXT record on the name _smtp._tls:
_smtp._tls.yourdomain.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@yourdomain.nl"
The reports are technical files (JSON). Just like with DMARC reports, use a separate mailbox for them. See Reading a DMARC report.
The order: first TLS-RPT, then MTA-STS set to testing, read reports for a few weeks, and only then enforce.
MTA-STS or DANE?
DANE does the same thing in a different way: the fingerprint of your mail server's certificate is stored in DNS (a TLSA record), secured with DNSSEC. DANE also protects the first connection, but only works if DNSSEC is enabled. MTA-STS doesn't need DNSSEC, but does need a website with a certificate. You may use them side by side; a sender that supports DANE will then give priority to DANE.
If your mail is hosted with WebOké, you can enable DANE in My WebOké in the same place as DNSSEC. WebOké then maintains the TLSA records for you. Read DNSSEC and DANE and Internet.nl checklist: getting 100% for your website and email.
Do you need it?
For most customers, no. Mail between large mail servers is nowadays almost always encrypted, and if you want to give your mail extra protection with WebOké, DANE is the simplest step. MTA-STS is mainly useful if your organization requires it, or if you expect recipients who use MTA-STS but not DANE. You don't need to configure anything for your own outgoing mail: that's determined by the server that sends your mail.
Setting it up yourself with a hosting package
You set the two TXT records in DNS Management in DirectAdmin or on the DNS tab in My WebOké. See Managing DNS records in My WebOké (with examples for CNAME, TXT, and external services).
The policy file must be located on the subdomain mta-sts. In your package you can create that subdomain in Subdomain Management; DirectAdmin will then automatically request an SSL certificate for it. See Creating and removing subdomains and Certificate for www, subdomains, and wildcard. In the subdomain's folder, create a folder called .well-known containing the file mta-sts.txt.
enforce. If a mail server name is incorrect, or the mail server's certificate doesn't match that name, mail will no longer arrive from senders that follow MTA-STS. Also, the policy file must be directly accessible: senders won't follow a redirect to another address. Start with testing, read the TLS-RPT reports, and contact us first if in doubt.Background: RFC 8461 (MTA-STS) and RFC 8460 (TLS-RPT).