sts-policy-invalid

How it appears in a report

"result-type": "sts-policy-invalid"

What it means

Senders fetched your policy file but could not parse it — a missing required field, a bad version line, or an mx entry that is not valid. A policy that fails to parse is treated as no policy at all.

Your mail server. This is your own receiving setup. The report describes senders failing to reach your MX, so the certificate, policy or DNS record at fault is yours to fix.

Worth being clear about the direction, because it is easy to get backwards: you publish TLS-RPT for your own domain, and senders report the failures they hit while delivering to you. So policy-domain and receiving-mx-hostname in your reports are yours, and sending-mta-ip belongs to whoever sent the report.

Why it happens

The format is strict and unforgiving: CRLF line endings, a version line first, and every MX host listed. Policies hand-edited in a text editor that saves LF endings fail this way, and so do policies whose MX list has drifted out of step with the actual MX records.

How to fix it

1. Check the file begins with version: STSv1 and includes mode, max_age and at least one mx entry.
2. Confirm the line endings are CRLF — the single most common cause, and invisible on screen.
3. Make sure every hostname in your MX records appears in the policy; one missing host fails only for that host, which makes it look intermittent.
4. Re-check after every edit, since an unparseable policy silently stops protecting anything.