certificate-host-mismatch: your certificate does not match your MX hostname

How it appears in a report

"result-type": "certificate-host-mismatch"

What it means

Your mail server presented a valid certificate, but it was issued for a different name than the MX hostname the sender connected to. Under MTA-STS or DANE the name has to match, so the session was refused and the mail did not arrive.

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

Most often a shared hosting or mail platform serving one certificate under its own hostname across many customer domains, or an MX record pointing at a name that was never added to the certificate. Changing MX records during a migration without reissuing the certificate produces this immediately.

How to fix it

1. Check which hostname your certificate is issued for and which one your MX record points at — this failure is the gap between them.
2. Reissue the certificate with your MX hostname among its subject alternative names.
3. If your mail is hosted, this is your provider’s certificate: send them the report and ask for the MX hostname to be covered.
4. Do not "fix" it by repointing MX at the certificate’s name unless that name really is your mail server.