And Email protocol backbone itself was not designed to be secure.

It's worse than internet packets over HTTPS -- the secure connection is established between client and server, so man-in-the-middle cannot decrypt it. In email, connections are only secure between relays, so any relay can decrypt read your email. You cannot guarantee what relays are used. Similar to SMS.

This might have been the case back in the day - in the 90s, young me would get a kick out of seeing just how many SMTP servers my email passed through. But now, email communication is "essentially" point-to-point, and relays in use are configured/whitelisted.

My SMTP server will pull up your MX and talk directly to it. It might be your Exchange server, a Google server, or a third-party scanner that then sends on to your "real" MX.

But gone are the days of "Hey, I only know a few places to send this message, so I'll send to one of them and they'll forward it". Nor can you do anything akin to route poisoning or other things to try to insert yourself into the message flow.

That's good to hear, however, as a compliance officer, what evidence I can provide to an auditor that our email communications are indeed encrypted?

It's not a secure messaging system. It's explicitly the opposite.

If you're sending plaintext out of an ostensible e2ee system, it's not an e2ee system. You have an 'end' that's not, you know, end-to-end.

The end that's relaying the plaintext is the user agent itself, not a third component in the system.

There is no 'relaying plaintext' in an e2ee system.

Sure, 100% agreed. But the way you phrased the earlier post implied that there was a third "end" to the system that was doing the plaintext leaking, and that's not the case (assuming I understood the description correctly, and it's accurate).