It depends on a few things.
First, BitLocker technically applies to individual partitions, not entire drives, but the fundamental rule is that BitLocker partitions that were unlocked at the time of backup will be unencrypted in the image file by default -- so you may want to enable Reflect's own encryption for image files to maintain data protection. Any BitLocker partitions that were locked at the time of backup will be encrypted in the image, but backing up locked partitions will mean your image files will be much larger because compression won't work with pre-encrypted data and the partition will appear 100% full to Reflect, so basically your images will always be the size of your entire partition, regardless of how much space you're actually using. This also means your restores will take a lot longer. Some other useful features also can't work when Reflect can't "see" the file system of the partition as well, such as Rapid Delta Restore (which can save a lot MORE time on restores in certain cases, even compared to "regular" restores of unencrypted partitions) and the ability to restore onto a smaller partition than the original source.
For restore scenarios, if you're restoring onto a new disk in your failure scenario, then if the backup was originally captured while the partition was unlocked, it will be restored unencrypted and you'll have to enable BitLocker again manually. Reflect will give you a warning about this. If the backup was captured while the partition was locked, it will be restored encrypted, and then yes you'd be able to access it with a Recovery Key or other protector. However, if you restored an OS partition (as opposed to a regular data partition), in which case your BitLocker partition likely uses a TPM, changing your hard drive might cause the TPM's platform integrity check to fail even if the partition was restored encrypted, in which case you may have to use your Recovery Key once. I have not tested this scenario. If your motherboard was replaced or the TPM was otherwise wiped, adding the TPM protector back to an existing encrypted partition is a bit of a chore. So for OS partitions, this is another reason to back them up while unlocked so they can be restored unencrypted and you can simply re-enable BitLocker. And if you want to be able to perform image backups from within Windows, then your OS partition will always be captured unlocked anyway.
Finally, if you're restoring onto the existing
BitLocker partition from which your backup was originally captured, e.g. you didn't have a drive failure but you simply wish to roll back your system to an earlier backup, if the backup was captured while unlocked and the target partition is unlocked in the Rescue environment at the time of the restore
(and has not been shrunk since the backup being restored was originally captured), then Reflect can run the restore in a way that preserves
the existing BitLocker protection. The Rescue Media wizard includes an option to automatically unlock BitLocker partitions in that environment if you're ok storing Recovery Keys on your Rescue Media, otherwise you can unlock them manually if you're comfortable with Command Prompt and want to use this feature. If the target partition is locked in the Rescue environment or is unlocked but has been shrunk since that backup was captured (which can happen as a result of upgrades to new Win10 releases), then Reflect will instead restore the partition unencrypted, and again it will warn you about this. You can read more about restores onto existing BitLocker partitions here: https://knowledgebase.macrium.com/display/KNOW7/BitLocker+Restore+Outcomes