The Developer Certificate of Origin protects the codebase from legal threat by requiring that each commit is signed, indicating that the contributor is authorised to make and license the commit (for example, if submitted while working for an employer).
To offer this protection, how strictly must this be adhered to? For example:
There is no complete legal protection. DCOs make it easy to prove that all contributors have agreed to the licensing conditions. But if the contributors do not actually follow the conditions in the DCO, you might still get code without a proper license. With respect to these risks, it is mostly irrelevant how often you sign your commits.
Regarding your concrete questions:
If you rewrite history (e.g. squash or rebase commits), then you get a new commit. Any signatures that are part of the original commits will be lost. So if you want to be able to trace signatures exactly, you should prefer history-preserving operations such as merging.
A git commit is immutable and references its parent commits, so the commit represents the complete history that led up to this state. So a git repository is a bit like a blockchain. Therefore, signing only the most recent commit on a branch implicitly signs the whole history up to and including that commit.
Seeing as the DCO is intended to mitigate legal threat, a per-commit policy technically maximises the mitigation. (But as pointed out by Amon, is practically irrelevant, as long as signatures are preserved.)
References:
