MTA-STS, TLS-RPT, and mail server certificates

How MTA-STS and TLS-RPT make sending servers use encryption, how to publish a policy that covers every mail server, and mail app certificates.

Mail servers encrypt mail to each other with STARTTLS when both sides support it. On its own, that’s easy to undo: someone who can tamper with the connection can remove the offer to encrypt, or send the session to their own server, and the sending server carries on regardless.

MTA-STS lets you publish a policy that tells senders to use an encrypted connection with a valid certificate for your mail servers, and not to deliver otherwise. TLS-RPT is its companion: senders send you reports about connections that failed, so you can see problems before you enforce the policy.

What SignalDNS checks

The MTA-STS record. We read the TXT record at _mta-sts. followed by your domain. There should be one record that starts with v=STSv1 and has an id.
The policy file. We fetch it from https://mta-sts.example.com/.well-known/mta-sts.txt, with your domain in place of example.com, the way senders do: over HTTPS with a valid certificate, without following redirects, up to 64 KiB, within six seconds. We check its fields, and that each MX host matches an mx line.
TLS-RPT. We read the TXT record at _smtp._tls. followed by your domain.
Mail app certificates. We check the certificates on the names mail apps connect to: mail., imap., and smtp. followed by your domain.

MTA-STS and TLS-RPT are optional, so not having them isn’t a finding. We say which mode MTA-STS is in when it’s set up, and flag either one when it’s broken.

What the record and policy look like

The record:

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

The policy file, served at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mx1.example.com
mx: *.mail.example.net
max_age: 86400

id is 1 to 32 letters and digits. Change it whenever you change the policy, so senders fetch the file again. A date and time works well.
mode is testing (report problems but deliver anyway), enforce (don’t deliver without a valid, encrypted connection), or none (the policy is switched off).
Each mx line names one mail server. *.mail.example.net matches one label, such as mx1.mail.example.net, but not mail.example.net or a.b.mail.example.net.
max_age is how long senders keep the policy, in seconds, up to 31557600 (about a year).
Serve the file as plain text (text/plain), which RFC 8461 asks senders to expect.

The MTA-STS record is broken

RFC 8461 says that unless there’s exactly one valid v=STSv1 record at _mta-sts, senders act as if you have no policy, so MTA-STS protects nothing. SignalDNS marks this as needing attention. The causes we report:

More than one record, such as an old one left beside a new one.
No id, or one that isn’t 1 to 32 letters and digits. id=2026-09-30 doesn’t work, because of the hyphens.

How to fix it: keep one record:

v=STSv1; id=20260930

The MTA-STS policy can’t be read

The record sends senders to the policy file, but we couldn’t read it there. Senders treat that as no policy. SignalDNS marks this as needing attention. The usual causes:

Nothing answers at mta-sts. followed by your domain, or the name has no DNS record.
An invalid certificate. It must be valid for the mta-sts. name itself. A certificate that covers only your main site’s names won’t do. See SSL certificate errors.
A redirect. RFC 8461 forbids senders from following redirects, so the file has to be at that exact URL. A host that redirects everything to your main site breaks it.
A status other than 200, such as a 404 because the file is at a different path.

How to fix it: serve the file at exactly /.well-known/mta-sts.txt on the mta-sts. name, with status 200, a valid certificate for that name, and no redirect. Cloudflare’s guide does this with a Worker; any static host that can serve the file at that path works too.

The MTA-STS policy is invalid

We read the file, but senders can’t use it. SignalDNS marks this as needing attention. We check that:

it has version: STSv1, spelled exactly like that;
mode is enforce, testing, or none;
max_age is a whole number of seconds, at most 31557600;
there’s at least one mx line, unless the mode is none.

Watch for a file written like the DNS record (v=STSv1; mode=enforce), = used instead of :, and several servers on one mx line. Each server needs its own line.

How to fix it: match the format in the example, then change the id in the record so senders fetch the new file.

A mail server isn’t in the MTA-STS policy

One of your MX hosts matches no mx line in the policy. A wildcard covers one label only, so *.example.net doesn’t cover a.b.example.net.

In enforce mode, senders that enforce MTA-STS refuse to deliver to that server. If no listed server works, they hold the mail and retry, and it can bounce. SignalDNS marks this as a problem.
In testing mode, senders still deliver, and report the failure if you have TLS-RPT. SignalDNS marks this as needing attention.

It happens when a mail server is added, or the domain moves to a new provider, and the policy isn’t updated.

How to fix it: add an mx line for every MX host, update the file, then change the id in the record. RFC 8461 says to update the file first, so senders that see the new id don’t save the old policy. When you move providers, list both the old and new servers in the policy before you change your MX records, and remove the old ones afterwards.

TLS-RPT reports

TLS-RPT (RFC 8460) asks sending servers to send you daily reports on their connections to your mail servers, including failures: certificates that didn’t check out, encryption that couldn’t be set up, and MTA-STS policy problems. It’s most useful while MTA-STS is in testing mode. The record:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

rua= lists where reports go: mailto: or https: addresses, separated by commas. Reports are JSON, so a reporting service makes them easier to read. Not having TLS-RPT isn’t a finding.

The TLS-RPT record is broken

Senders can’t use the record, so you get no reports. SignalDNS marks this as needing attention. The causes we report:

More than one v=TLSRPTv1 record. RFC 8460 has senders ignore them all.
No rua=, so reports have nowhere to go.
An address that isn’t mailto: or https:, such as a bare email address.

How to fix it: publish one record, starting with v=TLSRPTv1, with mailto: in front of the address.

Mail app certificates

Mail apps connect to your mail server by name, usually mail., imap., or smtp. followed by your domain, and check its certificate as a browser does. If it has a problem, the app shows a warning.

Where those names have a public IPv4 address, we connect with encryption from the start on the ports mail apps use:

mail.: 993 (IMAP), 465 (sending), and 995 (POP3)
imap.: 993
smtp.: 465

A port that doesn’t answer within two seconds isn’t offered there, so we skip it. A certificate needs attention when:

it has expired, or isn’t valid yet;
it’s for another name, such as the hosting company’s server name instead of yours;
it isn’t from a trusted authority, such as a self-signed certificate;
or the encrypted connection fails.

How to fix it: renew the certificate, or get one that covers every name your mail apps use. If your host’s certificate is only for its own server name, set your mail apps to use that name instead, as your host’s setup guide says. See SSL certificate errors and certificate renewal.

Moving from testing to enforce

Publish a TLS-RPT record, so you get reports.
Publish the policy file in testing mode, with an mx line for every MX host and a short max_age, such as 86400 (one day). Then publish the _mta-sts record.
Read the reports for a few weeks, and fix any server they show failing.
When the reports are clean, change the mode to enforce and raise max_age. RFC 8461 expects it to be weeks or longer. Then change the id.
Each time your mail servers change, update the policy first.

To switch MTA-STS off, publish mode: none with a short max_age and a new id. Remove the record and the file only once every earlier policy’s max_age has passed, as RFC 8461 describes.

Your provider’s guides

What we can’t tell from outside

We read the records, fetch the policy, and match your MX hosts against it by name. We don’t connect to your MX servers or test STARTTLS on ports 25 or 587, so we can’t tell whether they offer encryption or have certificates valid for their names, which enforcing senders require. We don’t check the policy file’s content type or see your TLS-RPT reports. Senders keep a policy for up to its max_age and look for a new one when the id changes, so always change the id.

Sources

Last reviewed September 30, 2026.