To avoid (even temporary) mismatches always publish multiple (two are enough) TLSA records. One for matching the current certificate chain, and another matching the *future* certificate chain.
You might ask how the *future* certificate chain can be predicted, but the answer is simple enough. While you may not know all the certificate details, you can control the public key that goes into the future certificate. This can be matched with a "3 1 1" record.
Therefore, the recommended key rotation approach is:
1. Whenever you *deploy* a certificate chain with a new key, at the same time (that way you won't forget later) generate the next key! And that time update your TLSA records to match both keys. You only need the next public key for this, the next private key could be password protected if you like, but for most sites just rotating the keys often and letting the OS protect the keys from all but the authorized account is enough.
_25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(curr key)> _25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(next key)>
2. When it is time to obtain a new certificate, generate the CSR from the previously generated *next* key (this may require decryption of the private if stored encrypted initially) and request the certificate, *but* do that only if the corresponding TLSA record is already published! Do the DNS lookup to verify.
3. To deploy the newly obtained certificate go back to step 1.