Some mail servers (MX hosts) have associated TLSA records with certificate usage 2 (DANE-TA) that match one of the retired Let's Encrypt issuer CAs. The retired CAs include:

All certificates issued by "X3" and "X4" have long ago expired. As of 2024-06-06, no new certificates will be issued by "R3", "R4", "E1" or "E2" and all extant certificates they issued will expire over the next 90 days.

All Let's Encrypt users publishing DANE-TA(2) TLSA records need to update their TLSA records to publish records that match the the intermediate issuer CAs that issued their current certificate and to pre-publish records for upcoming CAs if the current issuer is no longer active.

If your server's private and public keys are RSA keys, you can publish TLSA records matching just the "R*" CA public keys, and with ECDSA keys, just the "E*" CA public keys. If your server has both RSA and ECDSA keys, you'll need to publish TLSA records matching both the "R*" and "E*" issuer CAs. You can't rely on certificate renewal always using the same intermediate CA as before, or that the backup issuers might not be used instead. Therefore, list all "R*" and/or "E*" records. See the tables below for details.

Thus, SMTP server operators using DANE-TA(2) with Let's Encrypt certificates must publish the applicable groups of TLSA records from the below (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.

Note, however, that presently (July 2024) the Microsoft outbound mail servers appear unable to process more than ~12 TLSA records per MX host, so publishing all of the below may hamper email delivery from Microsoft. Best to choose only the RSA or only the ECDSA entries as appropriate for your server's key algorithm, and if already using the latest CAs (perhaps after an expedited renewal), you can stop publishinbg the records for R3/R4 and E1/E2.

CA tagRSA issuer CAs (certificates issued after 2024-06-06) IN TLSA 2 1 1 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba IN TLSA 2 1 1 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 IN TLSA 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 IN TLSA 2 1 1 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d IN TLSA 2 1 1 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
CA tagRSA issuer CAs (certificates issued before 2024-06-06) IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
CA tagECDSA issuer CAs (certificates issued after 2024-06-06) IN TLSA 2 1 1 3586d4ecf070578cbd27aedce20b964e48bc149faeb9dad72f46b857869172b8 IN TLSA 2 1 1 d016e1fe311948aca64f2de44ce86c9a51ca041df6103bb52a88eb3f761f57d7 IN TLSA 2 1 1 cbbc559b44d524d6a132bdac672744da3407f12aae5d5f722c5f6c7913871c75 IN TLSA 2 1 1 885bf0572252c6741dc9a52f5044487fef2a93b811cdedfad7624cc283b7cdd5 IN TLSA 2 1 1 f1440a9b76e1e41e53a4cb461329bf6337b419726be513e42e19f1c691c5d4b2
CA tagECDSA issuer CAs (certificates issued before 2024-06-06) IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270

Any other "2 1 1" records that were once associated with Let's Encrypt SHOULD NOT be used. They can't possibly match an unexpired certificate, and are just bloat in DNS TLSA lookup results, and an unnecessary security risk (if the obsolete keys are compromised). These obsolete TLSA records to avoid will before long include those matching the "R3", "R4", "E1" and "E2" CAs.

MX hosts whose TLSA records include only inactive CA key digests are no longer able to receive email from sending systems that perform DANE validation.

With a bit of care, one can instead publish TLSA records matching one of the "ISRG X1" or "ISRG X2" root CAs, but one then has to carefully ensure that the root CA certificates are appended to the server's chain file (not the case with chain files produced by, e.g., certbot), so the ACME chain file may require post-processing before it is configured as the MTA's certificate chain. The root CA public key hashes are:

CA tagISRG Root CAs IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 IN TLSA 2 1 1 762195c225586ee6c0237456e2107dc54f1efc21f61a792ebd515913cce68332

Of course even the above root CA TLSA records are not safe to then indefinitely ignore, the roots are also subject to occasional bitrot. Only the "3 1 1" records matching your server's public keys are under your control and change only when *you* decide to switch to new keys.

Hence, my best advice is to not play Let's Encrypt whack-a-mole, and use "3 1 1" records with stable keys (not automatically replaced with every renewal). You should choose when to rekey, and prepublish matching TLSA records before you do so. You may find danebot or similar tools helpful.

Finally, please avoid issuer TLSA records with selector Cert(0), i.e. "2 0 1" and "2 0 2". These are much more fragile, for example, some of the "E*" certificates will be issued by the RSA "X1" root, while others by the newer ECDSA "X2" root.

The table below lists MX hosts that are still publishing TLSA records matching the retired "X3" or "X4" CAs or the outdated R3 or R4 certificates issued by DST. It is sorted to list hosts that serve the most domains first. Once all extant certificates from "R3", "R4", "E1" and "E2" expire, any MX hosts still publishing these will also be added to the table.

signed domainshost name