PerfoMetrix

All guides · Security

MTA-STS and TLS-RPT: Encrypted Mail Delivery

Mail servers deliver email to each other over SMTP. Most of them encrypt the connection with STARTTLS, but by default it is opportunistic: if the encryption step fails or is stripped by someone on the network, the sending server simply delivers in plain text. It also does not check that the certificate belongs to your mail server. An attacker in the path can downgrade the connection or impersonate your server, and read or change mail meant for you.

MTA-STS (RFC 8461) lets your domain publish a policy that says: deliver to me only over TLS, only to these mail servers, and only with a valid certificate. TLS-RPT (RFC 8460) asks sending servers to send you daily reports about TLS connection problems, so you notice when something is wrong.

Both only concern incoming mail to your domain. They do nothing for domains that receive no email.

MTA-STS: the two parts

1. A DNS TXT record at _mta-sts.example.com:

_mta-sts.example.com.  TXT  "v=STSv1; id=20261028T120000"

The id is any string up to 32 letters and digits. Change it every time you change the policy file, so senders know to fetch the new version.

2. A policy file served over HTTPS at exactly https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.protection.outlook.com
max_age: 604800
  • mode is testing (report problems, deliver anyway), enforce (refuse to deliver over a connection that fails the policy) or none (withdraw the policy).
  • Each mx line lists a host name your MX records point to; a leading *. matches one label. Copy them from your MX records or your mail provider’s documentation.
  • max_age is how long, in seconds, senders cache the policy. Up to 31557600 (about a year) is allowed.

The mta-sts subdomain needs a valid certificate. Any static hosting works: a small virtual host on your web server, a static site host, or a serverless function that returns the text with Content-Type: text/plain.

TLS-RPT

One DNS TXT record at _smtp._tls.example.com:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Reports arrive as JSON (usually gzip-compressed) from large senders such as Google and Microsoft. A dedicated mailbox or a reporting service that parses them makes them readable.

Rolling out safely

  1. Publish TLS-RPT first and read reports for a week or two.
  2. Publish the MTA-STS policy in testing mode with a short max_age (a day). Check reports for failures: a missing mx entry or an expired certificate on a mail server.
  3. When reports are clean, switch to mode: enforce, raise max_age to a week or more, and change the id in the TXT record.

In enforce mode, a mistake (an expired certificate on your mail server, a new MX host missing from the policy) means senders that honour the policy hold or reject your incoming mail. Keep the certificate renewals automated and update the policy before you change mail providers.

Hosted mail providers such as Google Workspace and Microsoft 365 publish the MX names to use; some also offer to host the policy for you.

How PerfoMetrix checks this

We look up DNS TXT records only; we send no requests to your site or mail servers.

  • MTA-STS passes when _mta-sts.<domain> has a TXT record starting with v=STSv1, and needs attention when it is missing.
  • TLS-RPT passes when _smtp._tls.<domain> has a TXT record starting with v=TLSRPTv1, and needs attention when it is missing.
  • If the domain has no MX records, both are shown as information: they only matter for domains that receive mail.

We do not fetch the MTA-STS policy file, so we cannot tell whether it exists, which mode it uses, or whether its mx lines match your mail servers. Check that the policy URL returns your policy over HTTPS, and watch the TLS-RPT reports.

Further reading: RFC 8461: MTA-STS and RFC 8460: SMTP TLS Reporting.

Last updated October 28, 2026

Scan your website