First, it's ok for the company to send confidential info via email? I don't think so. Email is not a secure transport mechanism.
Second, email accounts are often the target of phishing and cyber attacks, so that's the last place you should enable the customer to store sensitive information.
Third, how does "noreply@" actually prevent the customer from sending a reply, disclosing the confidential information at every hop along the way to being bounced by your server? It doesn't. Or to "support" personnel; well maybe if you exclude your admins from the "support" classification but they're likely collecting those emails in an unnamed inbox or logging them somewhere? And what if the customer's (possibly third-party) admins are collecting bounces as they proactively monitor SMTP reputation for the domain and IP address?
Please, just erase the idea that it's ok to send confidential information via email from your head. Send a link to a password-protected page. If you want to be extra vigilant, require temp password via SMS to reset that password. And if you want to be hyper-vigilant, use TOTP as a 2FA mechanism for password reset. And if it really requires secrecy, send it via courier followed by an assassin to kill the courier. (Joking, not an incitement to criminal activity)
Realistically customers are going to fwd those emails anyway so this approach is more robust.
It seems like most information in these emails would be available to support staff typically though. It sounds like a niche case.
Everything does if you just glance at someone's comment online and dash one off.
How do you recognize which is the sensitive content and which isn't? How do you handle the case where you send out HTML emails, but the response strips all of the HTML and sends plain text back?
Others probably exist, but that is the one I know about.
Like another poster said, people can build their flaws into machines.