"-w, -raw
For encrypted datasets, send data exactly as it exists on disk. This allows backups to be taken even if encryption keys are not currently loaded. The backup may then be received on an untrusted machine since that machine will not have the encryption keys to read the protected data or alter it without being detected. Upon being received, the dataset will have the same encryption keys as it did on the send side, although the keylocation property will be defaulted to prompt if not otherwise provided. For unencrypted datasets, this flag will be equivalent to -Lec Note that if you do not use this flag for sending encrypted datasets, data will be sent unencrypted and may be re-encrypted with a different encryption key on the receiving system, which will disable the ability to do a raw send to that system for incrementals."
Source: https://zfsonlinux.org/manpages/0.8.5/man8/zfs.8.html
However, it become a pain-in-the-ass if you have recursive snapshots where only some of the datasets are encrypted. I think... in order to accomplish this, you need to send separate batches of snapshots... one for each set of encrypted vs. decrypted.
E.g.
/zpool/tmp # not encrypted
/zpool/home/someone # not encrypted
/zpool/home/someone/thunderbird # encrypted
$ zfs snapshot -r /zpool zpool@today
# this will probably bork
$ zfs send -v -w -R -I zpool@yesterday zpool@today | ...
# but this will work
$ zfs send -v -R -I zpool/tmp@yeserday zpool/tmp@today | ...
$ zfs send -v -R -I zpool/home/someone@yeserday zpool/home/someone@today | ...
$ zfs send -v -w -R -I zpool/home/someone/thunderbird@yeserday zpool/home/someone/thunderbird@today | ...
NOTE: I haven't fully explored this. But from experience, loading the key on the remote solves a lot of problems. The most import feature of encryption for us is encryption-at-rest. I just want to pull the AC plug and ensure that the data is protected.