If e-mail is only "best effort" delivery, is there a similar protocol with guaranteed delivery?

1. Fax delivery is NOT guaranteed - There are many ways a fax can fail. To name a few:

   • Misdialed number
   • Receiving fax out of paper (and not smart enough to realize)
   • Receiving fax out of toner (and not smart enough to realize)
   • Paper loaded upside-down in sending fax
   • Receiving fax is a shared device and the received fax gets taken and discarded by unintended recipient
     
     

2. SMTP IS a TCP-based protocol. Please consult RFC 821 and its successors RFC 2821 and RFC 5321.
   The underlying network protocol (TCP/IP) has nothing to do with reliable delivery (an application-protocol level thing).

3. Most SMTP servers keep logs of which messages (sender/recipient/messageID) passed through them, which can be admissible in court if you can demonstrate that the logs are unlikely to have been tampered with.
   Consult a lawyer.

4. There are mechanisms glued on to the SMTP protocol and associated programs for ensuring delivery (DSN, Return Receipts). Note that these themselves are best-effort / mutual cooperation extensions (Most mail clients let you elect not to send read receipts, and some clients can't issue a read receipt. Some MTAs can't/won't issue a delivery receipt.
   I'm not certain on the admissibility of these - it would depend on the court and any established precedent. Again, Consult a lawyer.

It's often established in law that faxes are accepted documents because their delivery is 'guaranteed'

Email server logs from sender and recipients are probably more reliable than fax reception confirmation.

The confirmation simply implies that "a" fax answered and received the document.

Server logs can confirm that "that specific" mailbox received the email and went through server A, B and C before getting in "that specific" mailbox.

I know that in Canada emails are accepted in courts of law. In large cases, a civil law suit can have an Anton Piller Order executed to seize server logs and mailboxes content.

The only way to have a guaranteed delivery is a direct peer-to-peer delivery. The sender has to establish a direct connection to the recipient and the recipient has to confirm the reception. Email is not a peer-to-peer protocol but a store-and-forward protocol. So there is not that kind of guarantee that is accepted in court. But sure the protocol tries to be reliable and if all servers in the chain play well then it is reliable.

But the technological delivery guarantee (in real life and in electronic mail/fax) does not give a guarantee on the message content. The logs or envelope only show that there was a delivery but can not show the message content. Even if you sign a message then it is only guaranteed that it was not manipulated on the way. But the original signed content could still be "Hello world!" instead of "You are fired!" and you only have the confirmation that a message has been sent.

Isn't this just begging for a TCP-based protocol that guarantees delivery to the same degree that fax does? Does such a protocol exist, and how entrenched is it?

To specifically answer the question - no such [network] protocol exists. Thus there is likewise no entrenchment of said protocol.

However, related to this topic, there are some important points about what one means about what "guarantee" [of delivery] even means or is possible:

1. There must be a means to authenticate the sender. However, there is no such facility in the FAX nor email hand-shaking process. The "from" FAX number can be spoofed much as the "from" email address is in so much spam/phishing messages.
2. There must be some means to ensure non-repudiation of the message itself such that it was not modified in-transit to even prove what was sent. Again, the underlying protocols make no such guarantee. PKI (using digital-signature technology in email, which is well supported though oft unused due to complexities, expiring certificates, etc), coupled with symmetric encryption and message hashing goes a long way to provide non-repudiation in email. These are well entrenched methods but not directly in the email communication space at large.
3. There must be some means to guarantee the message was actually delivered to the (actual intended) recipient. Logs are actually insufficient since they do not make any guarantees as to the above and then only weakly annotate a probably tendered delivery to the mailbox (not the recipient). This is even weaker than postal delivery. According to the Uniform Commercial Code (UCC) in commercial trade law: in addition to delivery to the agreed address, a communication of the delivery to the intended recipient that the [goods/message] are available is required. Email only stores the message at the target mailbox but this does not guarantee the recipient has been notified of its arrival. It is incumbent upon the receiver to constantly 'check' if the message arrived.

Lastly, there is an optional (and largely not cross-platform supported) email protocol to request (sender) and send (receiver) a delivery confirmation / receipt. However, this is seldom used, is not guaranteed and lastly does not disprove the receipt of the message by the recipient... rather that they may have either elected to not confirm the receipt, the receipt was not received by the sender or the delivery confirmation failed between incompatible email systems that do not support the same/version of this optional feature.

Many places that require guaranteed delivery use IBM's MQ Series or Sterling Software's products (recently bought by IBM)