"The term Release Candidate (RC) refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage of product stabilization (read QA cycle), all product features have been designed, coded and tested through one or more Beta cycles with no known showstopper-class bug." - Wikipedia.
It's important to understand this definition because the RC is the primary criterion for entering official QA release testing on behalf of the customer. QA may participate in testing prior to having a Release Candidate, but that testing doesn't count, because we don't have a product yet.
Let's break up the Wikipedia definition, for clarity:
"a version" means a build of the software product.
"with the potential to be a final product" means you could sell that exact version of the product if it passes QA qualification testing. It's a software version candidate that you could release to the customer.
"ready to release" means all the content is there. There is no coding or known bugs that have to be fixed still outstanding.
"unless final bugs emerge" means that the release candidate will not be released if such bugs are found in the official code freeze testing. This also means if such bugs are found, they must be fixed and a new RC declared with their fixes included. The new RC results in a new code freeze and a restart of qualification testing from QA.
The RC is the official hand off from development to QA, in which development says, "Here, I think this is ready." It's the start of QA's official testing on behalf of the customer.
The RC is important because the testing that occurred prior to it doesn't count. That testing is important and it may help the developers find bugs, but the product isn't complete, so you're not really testing the product. You're testing the prior version of the product. The next release is 2.0. You're still testing 1.0 until all the code and bug fixes for 2.0 are checked-in.
That is, until you have a Release Candidate.