I'm seeing in active use two distinct issuer certificates for the Let's Encrypt Authority X3 CA:
Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2016-03-17T16:40:46Z notAfter = 2021-03-17T16:40:46Z Subject CommonName = Let's Encrypt Authority X3 Subject Organization = Let's Encrypt pkey sha256: 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2016-10-06T15:43:55Z notAfter = 2021-10-06T15:43:55Z Subject CommonName = Let's Encrypt Authority X3 Subject Organization = Let's Encrypt pkey sha256: 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
While they share the same public key, and therefore the same matching "2 1 1" TLSA record, they unsurprisingly don't have the same full certificate "2 0 1" fingerprint.
This is a good opportunity to remind users that you should not pin the "2 0 1" or "2 0 2" fingerprints for any public CAs (including Let's Encrypt) in your TLSA records. If you don't control the CA, it is too easy to be surprised by an unexpected change in the issuer certificate (new root, updated expiry, ...).
While of course the CA can and sometimes will employ a new public key, key changes are less frequent, and it is more prudent to use "2 1 1" rather than "2 0 1" records (when not just using "3 X X" records).
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-r...
If you've not yet seen:
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
please do look over the materials there. In particular, implement *monitoring* for your server TLSA records making sure these match the certificate chain, and employ a resilient rollover scheme.
If you're one of the brave users with certificates for multiple algorithms (say both RSA and ECDSA), make sure your TLSA records match the chains for both algorithms.