Fixing "TLS negotiation failed" reported against your MTA-STS policy

After moving MTA-STS to mode: enforce, senders that honor your policy start refusing to deliver, and your TLS-RPT reports fill with failures like:

"result-type": "certificate.host.mismatch"
"result-type": "starttls.not.supported"

MTA-STS tells senders they must use STARTTLS with a valid certificate matching an MX host named in your policy. If any MX can't do that, the sender — correctly — declines to deliver rather than fall back to cleartext.

Why it happens

The policy file lists an MX that isn't in DNS, an MX whose certificate doesn't match its hostname, a server that doesn't offer STARTTLS, or an expired/self-signed certificate on one of the mail hosts. A single non-compliant MX breaks enforce mode.

Diagnose it

The MTA-STS check below fetches your _mta-sts TXT record and the https://mta-sts.example.com/.well-known/mta-sts.txtpolicy, validates the mode and max_age, and confirms every listed mx: pattern matches your real MX set.

Fix it

1. Make the policy's mx: lines exactly match your published MX hostnames (wildcards allowed).

2. Ensure every MX offers STARTTLS with a valid, unexpired certificate whose name matches the MX host.

3. Test in mode: testing first — it collects TLS-RPT failures without blocking mail — then promote to enforce.

4. Keep a TLS-RPT rua address so future breakage is reported to you, not discovered by bounced mail.