Your claims here seem slightly bad faith to me. So, I have decided to waste some of my time refuting them. What follows is an analysis of your comparison page (Link), feel free to refute any and all parts you feel are unfair. I will focus on Proton, as I am most familiar with their infrastructure. Hopefully, Tuta is also similar.
Lets Start
Analysis of their table headers
20 facts in comparison
Only 15 are actually listed. The 5 additional metrics in the header of the table (Hardenize, observatory, etc.) are measures of their website, not their service.
This is a test of their website (not service) security. It uses a very dated idea of HTTP security. Proton fails this due to no CSP policy (Link), which can lead to cross site scripting (XSS) attacks (Link). But, this does not matter on their website since:
- Their website actually does not handle any credentials at all. All actual credentials and mails are handled by their webapp or their native clients. Their webapp was found to be vulnerable to XSS attacks in 2022, and was immediately patched. (Link)
- Their website passes all other security tests, and uses HSTS and other measures for web security.
What about forwardemail? Well, since they use CSP, they must be invulnerable right?
No. Any and every site is ultimately vulnerable to XSS, due to how web works. Using CSP means they can disable inline JS attacks, but still need to load the JS from their CDN. Who is their CDN? Do they host their entire web infrstructure? Are they invulnerable to transport layer leaks? Are their web implementations bullet-proof? We will never know, since they have no audits of their service, and their website isn’t actually tested regularly by security experts (unlike proton, which actually is tested on the daily by actual malicious actors and experts.)
Proton fails due to IPv6 being denied. Also due to the same CSP issue above. See below more more details.
Proton fails here as they do not resolve IPv6. This is not a bug, its a feature. IPv6 is very new and immature in security, and legacy IPv6 is a privacy risk. Interestingly, forwardemail also failed this test until recently (around 2023). (Link)
The Mozilla observatory is deprecated now. And anyways, it’s just a repetition of the first test. No actual new difference.
I agree with this 
Analysis of their table of comparison
- Pricing, storage, attachment are all accurate for proton. (as they should be lol, public info)
- Open source: Correct claim that Proton backend is not open source. Appreciate forwardemail doing it all open-source, but again, no actual audit of the source. FLOSS is not security.
- Sandboxed Encryption: No source for their claim of Proton using what they say proton uses, and no source/audit of what they say they use. Additionally, if e2ee is implemented well, rogue employees or anyone else cannot access that data anyway. Finally a personal opinion: Having individual SQLite mailboxes might add another attack vector where now each mailbox can be easily separated from the larger database by a rouge employee, who can then handover specific data to malicious actor rather than the entire database. No clue if this is true, but that is what I think.
- Features: Don’t see the point in debating unlimited domains, aliases, etc. since that is part of pricing models used, and will differ from company to company. Kudos to forwardemail if they provide all this in free plan.
- SMTP, IMAP, POP3: Intentional implementation from Proton (Link). Kudos to forwardemail if they support all 3. Interesting thing to note is that both Proton and forwardemail provide SMTP and other protocols only in the paid plan. (Link). I also don’t see any source for their claim of vendor lock-in, since the Proton bridge is open source.
- API: Nice feature forwardemail has, but apparantly proton does not. Would be great to see audited reports of API security and its implementation.
- E2EE: Insane quote of protonmail “rewriting your email”. Is data corruption and misidentification of protocol used so malicious as to be deemed “rewriting”? The issue is simply Proton intentionally not implementing a feature of being able to use PGP keys not yet registered as a contact on mail service itself. It is a very opinionated choice, and one that people can dispute. But it is NOT, in any sense of the word, rewriting. I would recommend everyone actually read the linked Github issues (Link 1, Link 2). E2EE not being implemented would destroy Proton’s reputation and is a serious allegation. And anyways, we should move away from individually signing PGP keys and focus on automated implementations like Proton does.
- OpenPGP and WKD: No issues.
Analysis of their footer
They ask you to review them on Trustpilot. Let’s explore that. (Link)
They have 55 reviews on Trustpilot. Oldest review is from 16th Jan 2023, while the service has been active from 2017 apparently. Most of the 5 star reviews are from people with only 1 review and sound similar in structure. Most of the 1 stars have a comment underneath disputing them and calling the people who reviewed them liars. Seems very interesting.
They seem to have same problems as Proton Mail does on Trustpilot: Reviews by people who were banned. But the difference in proportion of reviews is simply due to the fact that protonmail has a free tier with their own address, while forwardemail does not.
Disclaimer: Trustpilot is known for fake reviews, deleting reviews, and blackmailing companies if they don’t pay them
For note, what Tuta does is how you do a comparison in good faith while still showing how your product is better (Link). I do not like how Protonmail does this comparison either, but they at least don’t have intentional misreads of competition’s features. (Link)