Infomaniak.com Swiss Cloud Provider Technical Support for SMTP problem

Infomaniak.com Swiss Cloud Provider Technical Support for SMTP problem
One fine day, when I am retired, and will have more time at hand to “have fun” than I do these days, I’ll switch my personal email to being fully decentralized self-hosting.
But these days fully running your own MTA properly requires more time than I personally am currently willing to give it.
In the meantime, I run my personal email in an admittedly somewhat weird set-up, like this:
Incoming
The domain registrar is Infomaniak.com a great Swiss Cloud Provider, which I can recommend - read on!
The DNS NS for it is a Cloud DNS on GCP. (This doesn’t really make all that much sense, as it would be much simpler to just use Infomaniak’s DNS; other than being “historical”, and a tiny little bit cheaper instead of paying them extra for Anycast . But hey, maybe we’ll throw some generative AI at DNS, too? 😼)
The
MXon that ismta-gw.infomaniak.ch. And I’ve configured that to forward my email to Gmail.
Outgoing
In Gmail, to reply, or write new email, I have configured it to treat as an alias and to send emails from a different address or alias using SMTP mail.infomaniak.com as per Infomaniak’s FAQ #468.
This worked great (through another set-up, which I had for many years before switching to Infomaniak), and at first seemed to “mostly” work fine with Infomaniak as well - until it regularly didn’t anymore, and sometimes “bounced” my outgoing email, with a failure reply from Gmail’s “Mail Delivery Subsystem” <mailer-daemon@googlemail.com> saying: “You’re sending this from a different address or alias using the ‘Send mail as’ feature. The settings for your ‘Send mail as’ account are misconfigured or out of date. The response from the remote server was: 535 5.7.0 Too many authentication failures”.
So I opened a Support Ticket with Infomaniak, describing the problem - actually not really hoping for much of a real reply, to be honest… but to my surprise, they actually properly debugged it! And replied: “The error you have encountered is due to the fact that the IP address used by Google services has been flagged as having a bad reputation in a public blacklist. This blacklist is used to protect our users from potential threats. We have taken steps to adapt our system accordingly and hope that this will resolve the problem.”
Wow. Cool. Serious real technical support is getting rarer these days than it naturally just should be. I’ll let some friends know about this positive experience with Infomaniak!
PS: On Email Security…
I cannot write about Email without a PS about this: Email is not private. Sending e.g. your tax documents and medical information (or what not) by email is pretty dumb actually - but fairly common, of course. While Email nowadays is at least encrypted in-transit, it will definitely be in clear-text at reception, and depending on where you have your Inbox, may well also be in clear-text when stored at rest. But email’s (in)security is “by old Internet design”, and very difficult to change comprehensively, at scale. Proton Mail tries, but that of course only really works between Proton Mail users, as well as to and from the 0.0000000001% of geeks or nerds 🤣 who actually have a PGP key. (And yes, Proton Mail’s “Password-protected” Emails are a “fun” idea, but I suspect that the “usability barrier” is just too high for recipients… I doubt the required out-of-band secret sharing really makes sense to most common mortals? But perhaps I should migrate my personal email setup to Proton Mail with custom domain anyway, they even nicely directly support SPF, DKIM, and DMARC…)
This is fundamentally wrong in 2024, and actually makes Email less secure than e.g. most of whatever-if-your-favourite-instant-messenger (mine is Threema; of the “big” ones, only Telegram does not encrypt, by default). Perhaps I should just use email less…
PPS: SPF, DKIM, DMARC
The Email Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC; see DMARC on Wikipedia) related DNS records have also been set-up. (One day when I have nothing more fun to do, I’ll also add one for Brand Indicators for Message Identification (BIMI).)
DKIM in particular is a PITA, because related TXT records are longer than 255 characters, and at least on GCP DNS you need to split the TXT record, and as per this tip on Stack Overflow: “The two quoted strings have to stay on the same line - in the same box in the Cloud DNS interface rather than in two separate boxes.”