When DANE delivery starts failing after a certificate change, first establish whether the key changed, whether the TLSA association uses that key, and which certificate each receiver actually serves. A generic certificate warning can hide a DNSSEC failure, an incorrect selector or a partial deployment. Fixing the wrong layer can leave mail queued while making the evidence harder to interpret.
Preserve the failing observation
References: RFC 7672 §2, RFC 7672 §3.
Record the sender implementation, timestamp, recipient domain, selected MX host, port, receiving IP and observed failure. Retain the DNSSEC validation result and the relevant TLSA answer alongside the certificate or its public fingerprint. If the sender retries another host, keep that as a separate observation. A dashboard summarizing the entire domain cannot replace endpoint-level evidence.
Distinguish handshake failure from authentication failure after a handshake. A network timeout does not prove that the TLSA digest mismatched. Conversely, receiving a certificate proves neither a trusted DNSSEC chain nor successful DANE authentication. RFC 7672 defines the discovery and validation steps separately. RFC 7672 sections 2 and 3.
Check usage and selector before comparing bytes
References: RFC 6698 §2.1.2, RFC 6698 §2.1.3, RFC 7672 §4.
For a 3 1 1 association, extract the served certificate's DER SPKI and calculate SHA-256. A certificate renewal that reuses the same key can leave this digest unchanged. A key rotation cannot. With a full-certificate selector, a renewed certificate changes the association even if the key is retained. Do not use a browser's certificate fingerprint interchangeably with an SPKI fingerprint.
The retained 7 November 2026 OpenSSL fixture, inspected but not rerun here, created certificates A and B with different keys and a reissue A2 with A's key. Its recorded calculations show A and A2 share the selected SPKI digest while B differs. It then deliberately compares B with A's association and records failure. The test uses real generated certificate bytes but is local, synthetic evidence rather than a captured production incident.
Reconstruct DNS and endpoint timing
References: RFC 7671 §8.1, RFC 7672 §2.1.
Compare the new-key activation time with publication of the overlapping association set and expiration of previous cached data. If B was deployed while a sender retained A-only records, a correct sender can reject B. Querying authoritative DNS after the incident and seeing B does not disprove that earlier cache state.
Check all backends and address families. A server that failed to reload might keep A while other servers use B. A new-only TLSA set would then fail only part of the traffic. DNSSEC failures have another timeline: signatures, delegation and resolver validation must be examined without casually treating bogus data as unsigned. RFC 7672 sections 2.1 and 4.
Restore consistency rather than disabling checks
References: RFC 7672 §3.1.1, RFC 7672 §4.
Where the key is not compromised, restoring a previously covered certificate or correctly overlapping associations may be appropriate, subject to the actual cache and rollout state. Coordinate mail and DNS owners and verify the repair from the sending side. Do not assume deleting TLSA will immediately remove cached requirements, and do not convert a security failure into unauthenticated delivery as a default workaround.
For DANE-EE, do not import every browser PKIX rule into the diagnosis: its certificate usage has specific authentication semantics, including no certificate-name match requirement and ignored certificate expiration for DANE-EE usage 3 under RFC 7672 §3.1.1. Do not extend this specific rule to every TLSA usage. That does not excuse expired operational certificates where other senders use PKIX or MTA-STS. Separately, the retained 7 November 2026 review evidence contains timestamped loopback STARTTLS sessions. The sessions were inspected but not rerun for this revision. A controlled client observes certificate B at a recorded 127.0.0.1 port, extracts the peer SPKI and refuses an A-only association. The corrected overlapping A-plus-B control accepts the route. Separately, Python/OpenSSL certificate verification rejects B against trust material A, while A succeeds. The private review package retains seven transcripts and peer certificate bytes for the four cases reaching certificate capture. Failed-handshake and no-STARTTLS cases do not contain captured peer certificate bytes. This is a small lab client with configured TLSA inputs, not an Internet DNSSEC result or production MTA incident. No message was sent; production acceptance still needs the intended endpoint and sender trace.