I know that that the ACK bit will be driven by the receiver of the CAN message. I'm wondering what would the situation be if you have multiple nodes listening to the same message. How would you confirm if all the nodes have received the message, since the ACK bit will only need to be driven by one of the nodes.
If by "received" you mean "the CAN controller accepted it and passed it on to the software" - this is provided for by the workings of the protocol.
If any receiver (or indeed the transmitter) notices an error in the message on the bus (for example some framing issue, a bit stuff error, or the CRC doesn't match etc.) then it will create an error frame, and no-one will accept the message - and it will then be retransmitted automatically by the transmitter who sent it. So, even if there was some bizarre noise affecting only one small part of the bus, if even one receiver spots an error, everyone will throw the message away. Note that this even occurs if the node spotting the error is not configured to accept the particular ID - this filtering happens only after the message is accepted by the lower level hardware.
The exception to this would be if the node that notices the error has gone into an Error Passive state - due to seeing too many errors. In this case, its error frame would include a "Passive Error Flag"(which is only made of recessive bits, so no-one sees it!). In this case, the other nodes (which did not see the error) would not be notified of this.
This is done to stop nodes with bad connections (for example) stopping the whole bus working. It is a corner case, when something else has already gone wrong, but is worth considering if your system is critical and you wish to consider the case of multiple independent failures.
This is handled by the higher level protocol layer. Usually CAN is regarded to be so robust that you don't need to worry about individual messages getting lost. It also utilizes collision avoidance. Network supervising nodes rather tend to check if every node on the bus that should be there is present, and leave it at that.
Common strategies is to have each node send out a "boot-up" message when it is up and running, or to have each node report in at regular intervals (sometimes called "heartbeat"). In some cases it might make sense to implement a manner of handshaking, by having the receiver respond with another message. Some protocols also utilize the RTR bits of the CAN frame for this purpose: to send out an empty request frame for a certain type of data, after which the receiver responds with a data frame with the same identifier as the RTR frame.