tlsa-invalid
Your DANE TLSA record does not match your certificate
By Jose Pollman · Published
How it appears in a report
"result-type": "tlsa-invalid"What it means
You publish a TLSA record for DANE, and the certificate your server presented did not match it. DANE has no fallback — a mismatch means DANE-validating senders refuse the session outright.
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
Nearly always a certificate renewed without updating the TLSA record. DANE pins the certificate or its key, so unless renewal reuses the same key, every renewal invalidates the record. Doing it in the wrong order takes inbound mail down from every validating sender until DNS TTLs expire.
How to fix it
- Compare your TLSA record against the certificate your MX is actually serving.
- Publish the new TLSA record *before* deploying the new certificate, and keep both valid across the changeover.
- Automate the TLSA update alongside renewal — a manual step will eventually be missed, and the failure mode is total.
- Treat this as urgent: it is breaking mail from every DANE-validating sender, not just the one that reported it.