certificate-expired

How it appears in a report

"result-type": "certificate-expired"

What it means

Your mail server presented a certificate past its expiry date, so senders enforcing a policy refused the session and their mail did not reach you.

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

Almost always automated renewal that stopped working, or a certificate renewed on disk and never reloaded by the mail server. SMTP daemons hold certificates in memory and do not notice a file changing underneath them the way a web server often does, so the renewal "succeeds" and port 25 keeps serving the old one. Certificate lifetimes are on a shrinking schedule, so anything depending on a manual step will fail more often over time.

How to fix it

1. Renew, then actually restart or reload the mail daemon — renewing the file alone is the classic half-fix.
2. Make the renewal hook reload Postfix, Exim or whatever terminates TLS on port 25, not just the web server.
3. Check the certificate as served on port 25 rather than 443. They are frequently different, and monitoring only 443 misses this entirely.
4. Add expiry monitoring against the MX hostname on port 25.