Reading one

Each failed session in a report carries a result type, and the type names the cause precisely enough to act on. There are only a handful worth knowing.

The failure types

Type	What happened	Where the fault is
`starttls-not-supported`	The receiving host did not advertise STARTTLS	Your MX host — or an attacker stripping it.
`certificate-expired`	The presented certificate was out of date	Your MX host’s certificate.
`certificate-host-mismatch`	The certificate did not cover the MX hostname	Your certificate’s subject names.
`certificate-not-trusted`	The chain did not validate to a trusted root	A missing intermediate, usually.
`validation-failure`	TLS negotiation failed for another reason	Protocol or cipher mismatch.
`sts-policy-fetch-error`	The policy could not be retrieved	Your policy host or its certificate.
`sts-policy-invalid`	The policy was fetched and would not parse	Your policy file.
`sts-webpki-invalid`	The policy host’s certificate did not validate	Your policy host’s certificate.
`dane-required`	The sender required DANE and could not validate it	Your TLSA records or DNSSEC chain.

Reading the pattern

One sender, all your MX hosts, certificate-not-trusted
   -> that sender's trust store lacks an intermediate you
      are not sending. Fix the chain, not the certificate.

All senders, one MX host, certificate-host-mismatch
   -> that host's certificate does not name it. A host added
      to the MX set without being added to the certificate.

All senders, all hosts, sts-policy-fetch-error
   -> your policy host is down, or its certificate expired.
      Nothing to do with mail servers at all.

One sender, starttls-not-supported, intermittently
   -> a middlebox on that path. Or, rarely, the thing
      MTA-STS exists to detect.

The two axes are the same as in DMARC reporting: sender and host. A failure confined to one sender is usually theirs; one confined to one host is yours and is narrow; one affecting everything is yours and is not a mail problem at all.

starttls-not-supported deserves a second look

Nearly every occurrence is a misconfigured host or a middlebox. The remaining fraction is an actual downgrade attempt, and this report is the only place it would ever appear — which is the entire argument for publishing TLS-RPT even without a policy.

Knowledge check

Reports from every sender show sts-webpki-invalid, but mail is still being delivered normally. What has happened?

The certificate on your policy host is invalid, so senders cannot fetch the policy — and MTA-STS fails open for those without a cached copy.
Your MX hosts’ certificates have expired.
Your policy file is malformed.
Nothing is wrong; mail is being delivered.

Correct — The certificate on your policy host is invalid, so senders cannot fetch the policy — and MTA-STS fails open for those without a cached copy. The webpki failure is specifically about the policy host, not your MX hosts. Delivery continues because the mechanism is designed not to let an unreachable policy block mail, which is exactly what makes this failure easy to miss.

Not this — Your MX hosts’ certificates have expired. That would report as certificate-expired. The sts- prefix on this type means the policy host.

Not this — Your policy file is malformed. That reports as sts-policy-invalid — fetched successfully and then unparseable. This one never got that far.

Not this — Nothing is wrong; mail is being delivered. Delivery is continuing because the mechanism degrades gracefully. The protection it was providing is gone, and no other signal would have told you.

The failure types

Reading the pattern

Try it on a real domain