In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.
The Internet is full of stories of people having trouble with large email providers (notably Google and Microsoft) accepting self-hosted users' mail. A self-hosted setup's IP starts with 0 reputation (or worse, depending on who owned the IP address beforehand) and will face throttling and outright blocking for a painful amount of time.
Furthermore, if you forward your email to e.g. a Gmail inbox, any spam sent to your address will go towards lowering the reputation of your forwarder, meaning that someone just has to send you a lot of spam to get your forwarder blocked from Google servers.
SPF, DKIM, DMARC and TLS all cannot mitigate the above.
Point 1: spf, dkim, dmarc is enough to get yourself neutral with gmail. You have to do it from get-go tho, before you tarnish your reputation. Being in DNSBL lists does not help either. Set up proper reverse dns entries also. Tls is completely optional. Haven't had any trouble neither with gmail nor ms using both residential and datacenter ips in two EU countries. I don't consider myself a hardcore linux admin specialising in mail, so there's that. As far as the second point, about forwarding spam goes, you're running a mailserver without spamassasin? What is this, the 1990s?
Counterpoint 1: I wrote my rant as a separate reply but the summary is that after twenty years of running my own e-mail and doing everything "right," I still got regularly binned by Google and Microsoft and (rarely) Yahoo, so I gave it up and switched to Fastmail. My experience, according to chats with others in my field, is not unique. I'd actually go so far to say that yours, with reliable delivery to Gmail with a small server, is the outlier.
> you're running a mailserver without spamassasin? What is this, the 1990s?
More like, relying on SpamAssassin to reliably and correctly classify spam is the anachronism here.
Even if SpamAssassin could do a good job of filtering spam today (which it can't), the set of messages that SpamAssassin classifies as spam will inevitably differ from the set of messages that Gmail classifies as spam, so the only thing this achieves is another point where you have to worry about false positives and training the classifiers.
Furthermore, the problem is exacerbated by poor support of forwarding in modern MTAs. They will queue all received messages first, and when Gmail rejects certain messages during the IMAP session (spam with high confidence, or messages it considers invalid), they result in a bounce, and the thus ensuing backscatter further degrades your mail server's reputation.
The closest thing to correct behavior is Exim's cutthrough delivery feature, which has been implemented "relatively" recently, and even so it is not complete and I've run into issues with it with non-textbook setups.
I'm trying to figure out how big those problems actually are. I can't say anything about the stories people tell, but I have no trouble sending to gmail nor anybody else.
Using configurations that provide redundancy is quite trivial. Also, what is the point of having several nines of SLA on a mailserver? Emails get retried a number of times before they are considered undeliverable.
SMTP requires sending servers to retry for at least 4 days, so 98.9% uptime over a year is guaranteed to be sufficient so as to not lose any mail ... so that is "several" as in "one", I suppose?
Of course you can have a lot more downtime than that, even just 20% uptime would be sufficient if timed right to ensure that no mail gets lost.
Or in other words: My central heating system has higher availability requirements than my mailserver, so I guess everyone in non-tropical places has a non-trivial endeavour going?
