TLS-RPT failure types, decoded one by one.

You published a _smtp._tls record, reports started arriving, and one of them has a non-zero failed-session-count with a result-type you have never seen before.

This page is the lookup table. Every failure type defined in RFC 8460, what each one actually means, the command that confirms it, and the fix. Jump straight to yours:

• certificate-expired · certificate-host-mismatch · certificate-not-trusted
• validation-failure · starttls-not-supported · DANE types
• sts-policy-fetch-error · sts-policy-invalid · sts-webpki-invalid
• No reports arriving at all

1. Reading the report first

Reports arrive as gzipped JSON. The structure that matters is small:

Three fields do the work. result-type tells you what broke. receiving-mx-hostname tells you which of your servers broke, which is the field people skip and then spend an afternoon checking the wrong host. failed-session-count tells you how much.

2. Certificate failures

certificate-expired

Means: the TLS certificate on the MX host named in receiving-mx-hostname has passed its expiry date. Senders that validate properly will not complete the session.

Confirm it:

Fix: renew and reload the MTA. Note that reloading the web server does nothing, mail servers hold their own certificate reference and usually need postfix reload, systemctl reload exim4 or equivalent. A surprising number of "still expired after renewal" reports are simply a service that was never reloaded.

If you are on Google Workspace or Microsoft 365, you should never see this for the MX hosts themselves. If you do, check whether a security gateway sits in front of them.

certificate-host-mismatch

Means: the certificate is valid, but the name on it does not cover the hostname the sender connected to. The sender resolved your MX to mx2.yourdomain.com, connected, and was presented a certificate for something else.

Confirm it:

The MX hostname must appear in the SAN list. The Common Name field is no longer sufficient on its own, modern validators ignore CN entirely.

Fix: reissue the certificate with every MX hostname in the SAN list, or point your MX records at a hostname the certificate already covers. The second option is often faster and is usually the better long-term answer, because it means your mail hostname and your certificate stop drifting apart.

The classic cause: a certificate for yourdomain.com and www.yourdomain.com installed on a mail server whose hostname is mail.yourdomain.com. Valid certificate. Wrong names.

certificate-not-trusted

Means: the chain does not reach a trusted root from the sender's perspective. Nine times in ten this is a missing intermediate certificate.

Why your browser says it is fine: browsers cache intermediates they have seen elsewhere and will often repair an incomplete chain silently. Mail servers do not. A certificate that looks perfect in Chrome can fail validation for every MTA on the internet.

Confirm it:

Fix: serve the full chain, leaf first, then intermediates, root omitted. Most ACME clients produce a fullchain.pem for exactly this; make sure your MTA points at that file and not at cert.pem.

validation-failure

Means: the catch-all. TLS negotiation failed for a reason that does not fit the more specific types.

In practice, the two live causes are protocol version and cipher suite. Providers have been deprecating TLS 1.0 and 1.1 on different schedules, so an MX host that only offers old versions will fail for some senders and succeed for others. That pattern, failures concentrated on one sending organisation while others are clean, is the signature.

Confirm it:

Fix: enable TLS 1.2 and 1.3. Disable 1.0 and 1.1. On Postfix, smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1.

starttls-not-supported

Means: the MX host is not advertising STARTTLS at all. It is accepting mail in plaintext only.

This one is never transient and always worth acting on immediately. It usually means a host was added to your MX set without TLS configured, a backup MX, a newly provisioned server, or an appliance somebody stood up during an incident and left in rotation.

Confirm it:

Fix: configure TLS on that host, or remove it from your MX records. Leaving a plaintext-only host in rotation means a portion of your mail arrives unencrypted regardless of what the other hosts do, and if you later enforce MTA-STS, that host will start bouncing mail.

3. MTA-STS policy failures

These only appear once you have published an MTA-STS policy. They are about the policy itself rather than your mail servers, and they are the reason to publish TLS-RPT before MTA-STS rather than after.

sts-policy-fetch-error

Means: the sender found your _mta-sts TXT record, tried to fetch the policy file over HTTPS, and could not.

Causes, in the order we would check them:

1. The mta-sts subdomain does not resolve, or resolves somewhere that returns 404.
2. The file is at the wrong path. It must be exactly /.well-known/mta-sts.txt.
3. HTTP redirects to HTTPS but the fetch itself is not served over HTTPS.
4. A firewall or WAF is blocking the sender's IP ranges. Bot protection on a static host is a real cause here.
5. Content type is text/html rather than text/plain.

sts-webpki-invalid

Means: the policy file was reachable, but the certificate on mta-sts.yourdomain.com failed validation. Expired, wrong hostname, or an incomplete chain.

This is worth understanding properly, because it is the quietest failure in the whole system. The certificate on your mta-sts web subdomain is what proves your policy is authentic. When it lapses, senders cannot trust the policy, so they discard it and deliver normally. Your protection switches off. Nothing bounces, nothing alerts, and the only trace is this line in a report nobody opened.

Fix: renew, and move the subdomain to a host with automatic renewal. Manually renewed certificates on this subdomain will eventually lapse, and by design you will not find out.

sts-policy-invalid

Means: the file was fetched and the certificate was fine, but the contents did not parse.

The usual suspects: a missing version: STSv1 line, a mode value that is not testing, enforce or none, multiple hostnames crammed onto one mx: line instead of one line each, a missing max_age, or an editor that saved the file as UTF-8 with a byte-order mark. That last one is invisible in every editor and breaks the first line.

DANE failure types

If you run DNSSEC and publish TLSA records, you may also see tlsa-invalid, dnssec-invalid, dane-required and sts-policy-fetch-error side by side. These indicate DANE validation problems rather than MTA-STS ones. The common cause is a TLSA record that was not updated when the certificate was renewed. DANE binds to the certificate itself, so renewal without a matching TLSA update breaks delivery for DANE-validating senders.

4. No reports arriving at all

Not a failure type, but the most common problem people have with TLS-RPT, and it produces silence rather than an error, which makes it hard to recognise.

The record is in the wrong place

It must be at _smtp._tls.yourdomain.com. Two underscore labels, that order. We have seen _tls._smtp, the apex, and _smtp_tls with an underscore instead of a dot. All three produce total silence.

Your own filtering is eating them

Genuinely common and slightly funny. Reports arrive as compressed attachments from senders your organisation has never corresponded with, which is a decent description of spam. Check the quarantine before concluding the record is broken.

Nobody sends you enough mail

Reports are generated by senders, so a domain that receives little mail gets few reports. If you receive mail from Google and Microsoft at all, you should see something within 48 hours. If your domain is parked or receives nothing, silence is correct.

The reports arrive and nobody reads them

The real failure mode, and the reason most TLS-RPT deployments are decorative. Set one rule: any report with total-failure-session-count above zero gets forwarded to whoever owns mail infrastructure. That is the whole process, and without it the record is doing nothing for you.

5. Triage order

1. Is it a pattern? Several days, or concentrated on one host or one sender. If not, ignore it.
2. Read receiving-mx-hostname. Fix the host that is failing, not the one you assume is failing.
3. Certificate types first, expired, mismatch, untrusted. These are the most common and the easiest to confirm with one openssl command.
4. sts-* types next. These are about your policy hosting, not your mail servers. Check the mta-sts subdomain's certificate before anything else.
5. Re-check after 48 to 72 hours. Reports are daily and senders cache, so a fix does not show up immediately.

6. Frequently asked questions

What does certificate-host-mismatch mean in a TLS-RPT report?

The certificate presented by your mail server is valid, but the hostname the sender connected to does not appear in the certificate's Subject Alternative Name list. Check the receiving-mx-hostname field to see which host, then verify its SAN entries with openssl s_client. Fix by reissuing the certificate to include every MX hostname, or by pointing MX at a name the certificate already covers.

What is sts-webpki-invalid?

The certificate on your mta-sts.yourdomain.com subdomain failed validation, so senders could not trust your MTA-STS policy and discarded it. Because MTA-STS fails open, your mail keeps flowing and your protection silently stops working. Renew the certificate and move the subdomain to a host with automatic renewal.

What causes sts-policy-fetch-error?

The sender found your _mta-sts TXT record but could not retrieve the policy file. Check, in order: that mta-sts.yourdomain.com resolves and returns 200, that the path is exactly /.well-known/mta-sts.txt, that it is served over HTTPS, that no firewall or bot protection blocks the sender, and that the content type is text/plain.

Why am I not receiving any TLS-RPT reports?

The most common cause is the record being in the wrong location. It must be at _smtp._tls.yourdomain.com, two underscore labels in that order. Confirm with dig +short TXT _smtp._tls.yourdomain.com. If the record is correct, check your spam quarantine, since the reports arrive as compressed attachments from unfamiliar senders and are frequently filtered.

How many TLS-RPT failures are normal?

A small number of failures against a large number of successes is normal, networks drop connections. Investigate when the failure rate exceeds roughly 5% of sessions, when a non-zero count persists across several days, or when failures concentrate on a single MX hostname while your other hosts stay clean. The one exception is starttls-not-supported, which is never transient.

My certificate works in the browser but TLS-RPT says certificate-not-trusted. Why?

Browsers cache intermediate certificates they have encountered elsewhere and will silently repair an incomplete chain. Mail servers do not. If your server sends only the leaf certificate without intermediates, browsers succeed and MTAs fail. Check with openssl s_client -showcerts and count the certificates returned, one means the chain is incomplete. Serve the full chain instead.

What is the difference between TLS-RPT and DMARC aggregate reports?

Different layers entirely. DMARC's rua reports on authentication, whether SPF and DKIM passed and aligned for messages claiming to come from your domain. TLS-RPT reports on transport, whether the connection carrying those messages was encrypted and validated. A message can pass DMARC perfectly while having been delivered in plaintext, and TLS-RPT is the only thing that would tell you.