Some mail servers (MX hosts) have associated TLSA records with certificate usage 2 (DANE-TA) that match the just retired Let's Encrypt issuer CA ("X3") and/or its emergency backup "X4". All Let's Encrypt users publishing DANE-TA(2) TLSA records need to update their TLSA records to publish records that match the current intermediate issuer CAs.

In more detail, there are multiple Let's Encrypt issuer certificates that may be used in automated certificate renewals: two primary certificates ("R3" and "E1") and their emergency backups ("R4" and "E2"). Thus, SMTP server operators using DANE-TA(2) with Let's Encrypt certificates must publish the following list of TLSA records (possibly in addition to "3 1 1" records matching the server public key) for each of their MX hosts in order to prevent delivery failures:

CA tagRecommended TLSA Records to match Let's Encrypt issuer CAs IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 IN TLSA 2 1 1 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03

The "X3" and "X4" hashes are no longer needed, all certificates issued via "X3" have now expired, and all replacements are using "R3" or "E1".

MX hosts whose TLSA records include only the "X3" and/or "X4" digest are no longer able to receive email from sending systems that perform DANE validation.

Also, the TLSA RRsets of some MX hosts list the hashes of R3 and/or R4 issuer certificates issued by DST that expired on 2021-09-29. These hashes should not be used, and the expired certificate in question should not appear in your server certificate chains. The correct R3 and R4 certificates to use are signed by ISRG.

Expired DST-issued R3/R4 CA hashes
2 0 1 730c1bdcd85f57ce5dc0bba733e5f1ba5a925b2a771d640a26f7a454224dad3b
2 0 2 dd35f36f0db81b56a1cc9f734e4258d66125530fa8cfaf6b5efe79d517318302       4ebc78543b69bdd89fde3724816a035a20cbdcedb5e44dd2b746ab9b0b304ccd
2 0 1 5a8f16fda448d783481cca57a2428d174dad8c60943ceb28f661ae31fd39a5fa
2 0 2 5df0164684f2640bedcdbe82abc7335a12389974882fb120afe5f85f1cf1db2b       071e81a17adca47af1050b6bbb39afd1e09c33b0f2347b9122758f3ad2036d1a

Please avoid issuer TLSA records with selector Cert(0), i.e. "2 0 1" and "2 0 2". These are much more fragile, and worse, "R3" and "R4" are cross-signed by two different issuers, so there are two differnt full cert hashes for R3 and R4, but just one underlying public key and corresponding "2 1 1" hash. The same cross-signing issue can arise with the other issuer CAs at some point in the future.

The MX host table below is sorted to list hosts that serve the most domains at the top.

signed domainshost name