I was playing with Proton Mail for some new FEI Insights, and discovered that it is altering MIME message contents very significantly upon receipt. If you are a Proton Mail user and have some insights, I would be interested to hear them.
Here is a quick summary of what I observed:
Setup
Simple email with HTML and plain text bodies sent from Gmail to Proton Mail without encryption. The received email was exported using Proton Mail web interface in MIME format.
Observations
Mild Problems
Proton Mail changed the casing on some of the email headers. For example, MIME-Version: became Mime-Version: and Message-ID: became Message-Id:. This is not a huge deal as it would not affect DKIM / ARC with relaxed canonicalization (simple canonicalization would be affected, if including those fields).
Concerning but Reversible
Proton Mail normalized the value of the origination date header. Date: Wed, 3 Sep 2025 11:33:49 -0700 became Date: Wed, 03 Sep 2025 11:33:49 -0700. The header value change would throw off DKIM / ARC verification, but can be reversed if you know what to expect.
Severe Problems
The original message had a multipart/alternative content type, the alternatives being HTML and text versions of the body. Proton Mail converted this to a multipart/mixed → multipart/related hierarchy, and got rid of the text body to boot 
The original Gmail webmail MIME boundary delimiters were replaced with Proton MIME boundary delimiters.
The text and HTML bodies were originally 7-bit encoded. After discarding the text body, Proton Mail re-encoded the HTML body using Base64.
The Content-Type headers of the MIME entities were re-written even in cases where nothing else changed. For example, Content-Type: text/html; charset="UTF-8" became Content-Type: text/html;charset=utf-8.
The problems in this category would absolutely wreck DKIM & ARC verification, and are very challenging to reverse.
Other Notable Issues
Another interesting observation was that every time I exported the message, I got a new set of Proton Mail MIME boundary delimiters. So, if one exports / downloads the same message twice, each copy has a different cryptographic hash.
This might mean that instead of encrypting and storing the received MIME message as a whole, Proton Mail is separating it into its subcomponents for storage and piecing it back together during each export. Hard to tell why this is needed, but perhaps for selective access control and making it easier to perform indexing and search on the local client side as described here.
Conclusions
In summary, when the test email is sent to a regular email host such as Gmail or Yahoo, DKIM & ARC verify and the email passes forensic verification with flying colors. When the same email is received by Proton Mail, the received copy is significantly changed and DKIM & ARC no longer verify.
After running into these issues, I did some cursory research to see if similar problems had been reported, and found a number of seemingly related reports. Here is one that also involves Bridge:
https://www.reddit.com/r/ProtonMail/comments/y6p5m4/encrypted_emails_sent_through_proton_bridge_are/
I personally appreciate Proton Mail’s security and privacy features and have had them on my list of quality email hosts. That said, I was disappointed to see that the privacy benefits come at a great cost—the original message is lost and is reconstructed upon receipt by Proton Mail.
Without having an intimate understanding of how their system works, it is hard to comprehend how/why such severe changes to inbound messages are needed for Proton Mail to be able to encrypt them at rest (they are already received by Proton Mail in plain text, so no real end-to-end encryption is at play in this case).