MTA-STS and TLS-RPT: encrypting incoming email step by step

The problem MTA-STS solves

Mail servers encrypt connections with the STARTTLS command, but usually only "if possible". The sender connects to your MX server, asks whether it supports encryption, and only then switches it on. Someone sitting on the path can strip the STARTTLS offer from the reply, and the sender will then deliver the message in plain text. The sender also has no way to know that your domain requires encryption, so nothing looks wrong to it. Without such a requirement, rejecting the mail would be worse for the sender than sending it unencrypted.

MTA-STS (RFC 8461) gives the sender that knowledge. A sender that supports MTA-STS fetches your policy over HTTPS, remembers it for the time stated in the file and, in enforce mode, does not deliver mail to a server that fails the conditions. The policy covers email coming in to your domain. Encryption of the email you send depends on the policies of the recipients' domains.

SecVault Auditor checks two things: whether the domain publishes MTA-STS (and how) and whether it has TLS-RPT. Encryption on the MX server itself (STARTTLS and its certificate) is a separate check. The method is described on the methodology page.

The three parts of MTA-STS

You need all three. If any one is missing, senders will not apply the policy or will conclude there is none.

1. A TXT record in DNS

The record name is _mta-sts.<domain>, for example _mta-sts.yourcompany.com. The value:

v=STSv1; id=20261110T090000

• v=STSv1 must be the first field.
• id identifies the policy version: 1 to 32 characters, letters and digits only (RFC 8461, section 3.1). A date and time without special characters works, for example 20261110090000. It must differ from the previous one, but the RFC implies no ordering, so it need not increase.
• TXT records at that name that do not start with v=STSv1; are discarded. If exactly one valid record does not remain, the sender assumes there is no policy. The Auditor looks for a record starting with v=STSv1.

2. The policy file over HTTPS

The file lives at https://mta-sts.<domain>/.well-known/mta-sts.txt, that is on a separate host named mta-sts in your domain. The format is key: value pairs, one per line. Example:

version: STSv1
mode: testing
mx: mail.yourcompany.com
mx: *.mail-provider.example
max_age: 86400

• version must be STSv1.
• mode is enforce, testing or none (described below).
• mx is one line per allowed mail server. You write a full host name or a pattern with a leading asterisk that covers only the leftmost label of the name (RFC 8461, section 4.1). The names in the example are fictional.
• max_age is the time in seconds a sender may remember the policy. It is a non-negative integer and the RFC sets an upper limit of 31557600 (about one year). The 86400 in the example is one day and is only an example.
• Unknown fields are ignored, and when a field other than mx repeats, the first occurrence is used.

3. A valid certificate for mta-sts.<domain>

The host mta-sts.<domain> needs a DNS name and a certificate that is valid for that name, issued by a trusted authority and not expired (RFC 8461, section 3.3). The sender accepts only an HTTP 200 response. It must not follow redirects (3xx) and must not use HTTP caching. The content type should be text/plain. An expired certificate is the most common way a working policy stops working months later, so set up automatic renewal: what to do when a certificate has expired.

The certificate of the MX server is a different matter from the certificate of the mta-sts host. In enforce mode the sender checks both: whether the MX name matches one of the mx lines and whether the MX presents a valid certificate for that name.

Modes: testing, enforce and none

• testing: the sender evaluates the policy, but mail is still delivered when the conditions are not met. If the sender supports TLS-RPT, it sends a report about the failures (RFC 8461, section 5). This is the mode for rollout and observation.
• enforce: the sender does not deliver to a server that does not match the mx list, has no valid certificate or does not support STARTTLS. The delivery is treated as a temporary failure and retried.
• none: the domain is treated as having no active policy. It is used to switch MTA-STS off (see below).

The Auditor rates the mode like this: enforce is a pass, testing is a warning with advice to switch to enforce after the test period, and a policy without a valid mode (no mode line or another value) is a warning "MTA-STS policy without a valid mode". A missing record gives "No MTA-STS - encryption when receiving email is not enforced".

A safe rollout order

1. Make sure every MX server in your DNS supports STARTTLS and has a valid certificate for the name in the MX record. You can check this in the free audit. If your email is hosted by a large provider, its documentation tells you which mx lines to use.
2. Turn on TLS-RPT (section below) so you receive reports from the start.
3. Create the host mta-sts.<domain> with a certificate and publish the policy file in testing mode. Start with a short max_age so that a mistake in the policy is not remembered for long.
4. Add the _mta-sts TXT record with the first id.
5. Read the TLS-RPT reports for a few weeks. The RFC gives no required test period, so that is your call. Look for errors such as sts-policy-invalid, certificate-host-mismatch or starttls-not-supported.
6. When the reports are clean, change mode to enforce, raise max_age to a value you consider reasonable (the RFC limit is 31557600) and change the id in the TXT record.

Changing the policy means changing the id

Senders keep the policy in memory for the max_age time and refresh it when they see a different id in DNS. Edits to the file without a new id are not picked up right away. The RFC recommends an order (section 8.1): update the policy file first, then change the id in the TXT record, so that a sender does not cache the old policy under the new id. Keep old policy versions available until the TTL of the TXT record has passed.

This also applies to a new MX server. Add its mx line to the file and change the id before you move mail to it, because in enforce mode a sender that remembers the old list will not deliver to the new server.

How to switch MTA-STS off

Deleting the record is not enough, because senders keep remembering the policy for max_age. According to the RFC (section 8.3): publish a policy with mode none and a short max_age (the RFC gives one day as an example), change the id, wait until previously cached policies expire, and only then remove the record and the file.

Most common mistakes

• No mta-sts host or no certificate. The TXT record exists but the file cannot be fetched. The Auditor then reports "An MTA-STS record exists, but the policy cannot be fetched" with the error name, and senders behave as if there were no policy, or apply an old one if they have it cached.
• The policy returns a code other than 200. The Auditor reports "An MTA-STS record exists, but the policy returns HTTP" with the code. Senders behave the same way: only 200 is a valid response.
• A redirect instead of the file. The mta-sts host sends visitors to another address (for example from http to https or to another domain) because the web server has a general redirect rule. Senders do not follow redirects, and neither does the Auditor, so you will see a 301 or 302. The file has to be served directly at the correct HTTPS address.
• Wrong content type. The RFC says a sender should check that the response is text/plain. A file served as text/html or application/octet-stream may be rejected. The Auditor does not rate this separately, but check it in the response headers.
• The mx lines do not cover all MX servers. This is the error the Auditor words most strongly. In enforce mode it is an error: "The MTA-STS policy (enforce) does not cover the mail server ... senders that honour it will not deliver email to that server". In testing mode it is a warning to fix it before switching to enforce. A typical cause is a backup MX added, or a change of mail provider without updating the file. A pattern with an asterisk covers one label only, so *.yourcompany.com does not match a.b.yourcompany.com.
• A max_age that is too short. With a value of a few minutes the sender barely remembers the policy, and an attacker who blocks the file download has an open path. In enforce mode a longer time makes sense, weeks or more (RFC 8461, section 3.3: values of weeks or more are expected). Keep a short value for the test phase.
• A max_age that is too long without a reason. A value near the 31557600 limit means senders will remember a faulty policy for almost a year. Until you have clean reports and a stable certificate on the mta-sts host, keep it short.
• Editing the file without changing the id. Senders may keep using the old version for a long time.

TLS-RPT: encryption reports

TLS-RPT (RFC 8460) is the companion to MTA-STS. Senders that support it send you a daily summary report on how their connections to your servers went. The record is a TXT at _smtp._tls.<domain>:

v=TLSRPTv1; rua=mailto:[email protected]

• v=TLSRPTv1 is the version and rua is where reports go. Two schemes are supported, mailto: and https:, and several addresses are separated by commas.
• Reports are JSON files, usually compressed with gzip (media types application/tlsrpt+json and application/tlsrpt+gzip), delivered by email or by HTTPS POST. A report period is normally a full UTC day.
• A report contains the policy type (sts for MTA-STS, tlsa for DANE, or no-policy-found), the number of successful and failed sessions and the reasons for failure, including starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid. Each failure comes with the sender IP address and the MX host name.
• Minor transient failures (a busy network, a TCP timeout) do not have to be reported.

Turn on TLS-RPT before enforce, because it is the only way to see whose mail would be rejected after the switch: senders that have trouble with your certificate show up in the reports from testing mode. Without reports you enable enforce blind. The rua address should be a dedicated mailbox or an alias, because reports pile up. The Auditor checks only that a record starting with v=TLSRPTv1 exists. The pass message is "TLS-RPT: reports on encryption problems are being sent", and when the record is missing: "No TLS-RPT (reports on TLS errors during delivery)". It does not check that the rua address works, so wait a day and look in the mailbox.

TLS-RPT works independently of MTA-STS. You can publish only the TLS-RPT record to see TLS errors at senders, even without a policy.

Where to host the policy file

The file has a few lines and almost never changes, so you do not need a dedicated server.

• Your own web server. Add a virtual host for mta-sts.<domain> with a certificate (automatic renewal is fine) and the file in the .well-known directory. Turn off general redirects for that host and make sure the file is served as text/plain.
• A static hosting service (static sites, file storage with a custom domain). There is one condition: it must serve the name mta-sts.<domain> with a valid certificate and return the file directly, without a redirect, with code 200 and type text/plain. Verify this after deployment by fetching the headers and the body.
• Your email or DNS provider. Some providers publish the policy for you or offer a ready-made switch. Check the panel for this and for the mx lines it writes. Do not assume it exists.

The hosting server does not have to sit next to the mail server. It is actually better if one outage does not take both down. Senders fetch the file from the internet, so the mta-sts host must be publicly reachable.

Related guides

MTA-STS protects the transport encryption, not the sender's authenticity. That is the job of DKIM and DMARC. Check the whole email setup of your domain in the free audit.

Sources

• RFC 8461, SMTP MTA Strict Transport Security (MTA-STS): rfc-editor.org/rfc/rfc8461
• RFC 8460, SMTP TLS Reporting: rfc-editor.org/rfc/rfc8460