People keep saying email is decentralised, and on a technical level that's true. Even today, anyone can fire up an email server and start sending emails to anyone else out there.
In practice, though, I've seen those who run their own mailservers increasingly complaining about the difficulty of managing their server's "reputation", especially in the spam filters of Big Tech companies. A lower reputation means your email are more likely to end up in a spam box—which makes Big Email very happy, because it'll tempt you to sign up and pay for their services after all (you don't always pay in money, but you do always pay).
To keep themselves happy, Big Email has very opaque or often nonexistent rules about how to get your email server off the blacklist if it ever falls into one. I learnt this the hard way when Snipette's servers got blacklisted due to a silly own-goal we did.
You see, even though we had our own mailbox, most of us were too comfortable with Gmail's familiar web interface to think of anything else. So we ended up using it the dumb way, which was to forward all snipettemag.com emails to our gmail.com address. Like all public email addresses, we used to get a lot of spam emails (would that actual article submissions were that frequent!) which we'd throw disdainfully into our spam box...or rather, to Gmail's spam box. That's where the trouble began, because all the email we were receiving was being forwarded from snipettemag.com to Gmail, so what Gmail learnt was that "dog, these snipettemag.com people sure do send a lot of spam!"
This led into a Black Mirror-esque series of bounced emails and documentation stonewalls to get our IP address reputation back—or at least, it seemed like things might go that way. Fortunately, we happened to anyway be shifting to a different webhost at the time, which came with a different IP address That allowed us to start again with a clean state (at the expense of whichever poor folks our old IP address was next assigned to).
Rather than auto-forwarding Snipette emails to Gmail's inbox, the better solution would have been to link up Gmail so that it managed Snipette's inbox directly (yes, adding an external IMAP server is a thing in Gmail, as is setting up an external SMTP server which we'd already done to be able to send emails from snipettemag.com rather than gmail.com).
Fortunately, we managed to go to the even better solution, which was to abandon Gmail entirely in favour of NextCloud Mail, whose interface had become good enough to use by then. (Local email clients like Thunderbird are also an option if you have a device of your own and don't have to keep borrowing your parents').
While things turned out well for Snipette, the lesson here is that if you care about delivering emails to Big Email users, mistakes can be costly. Worse, this helps spread the impression that email is "highly complex" or "difficult to set up" which would discourage new people from trying it at all. I don't know if this is just an impression that spread or something that has been deliberately perpetuated (maybe a bit of both?). It may be true of a very large-scale or specific email setups, but I've been hosting email myself on one domain or another since I was 12, with the process usually being so guided that setting it up was more like an automatic afterthought than a conscious decision.
This can have an impact even at the national level. I remember my friends studying at Rishi Valley, a small alternative school operating in rural Andhra Pradesh, emailing me using the local Rishi Valley operated email server. Today, by contrast, even IIT Madras opts to use Big Email for its newer programmes. (IIT Madras still operates its own email servers for its main domain, as do the IITs of Kharagpur, Bombay, Kanpur, and Delhi. Concerningly, every other IIT, despite being among the ranks of the country's top technical institutions, relies on Google or in some cases Microsoft instead of running their own email server.) Meanwhile, the government, in trying for digital souvereignty, has instead taken a leap backwards by shifting away from selfhosting to a Big Tech firm, albeit a local one.
Email isn't hard, but battling Big Email's spam filters can be frustrating and exhausting. Taking advantage of this are many "email delivery services" that have sprung up, offering you an API to deliver your emails for you in exchange for a subscription. They say they have the infrastructure to make sure your emails are delivered, but the more important ingredient is the organisational and legal clout and scale to make sure Big Email allows them in.
All this is much more work than it should be. And that's why, every so often, one selfhoster or another pops up saying they're giving up and going to switch to a bigger provider instead. This doesn't necessarily have to be Big Email—there are many not-so-big email providers to choose from as well—but it does defeat the goal of everyone being able to (theoretically) spin up their own email server.
A common problem faced by selfhosters is being in the stage where emails from your server aren't all summarily marked as spam, but the first email you send to any new Big Tech contact is marked so, nipping in the bud what could otherwise have been an engaging or fruitful conversation.
At Snipette, we do the hack of sending our first email to a new contact through one such delivery provider, Mailgun, with whom we already have a subscription for bulk delivery of our newsletter (a whole different story in itself). When they reply, we continue the conversation through our own mail server, because their spam filters would have figured out by then that ours is a desirable email.
Of course, this is only necessary for those providers which actually treat our emails in such a way. For us, it's mainly Google. Since a lot of places which use their own domains are still hosted on Google (looking at you, new IITs) a quick way to check this is to look up the MX record and see if it points to Google's domains.
$ dig -t mx iitm.ac.in
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> -t mx iitm.ac.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58599
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;iitm.ac.in. IN MX
;; ANSWER SECTION:
iitm.ac.in. 43200 IN MX 20 mailx2.iitm.ac.in.
iitm.ac.in. 43200 IN MX 10 mailx1.iitm.ac.in.
iitm.ac.in. 43200 IN MX 40 mailx4.iitm.ac.in.
iitm.ac.in. 43200 IN MX 30 mailx3.iitm.ac.in.
;; Query time: 216 msec
These records aren't showing up any Google related domains like aspmx.l.google.com to me, so if I'm writing to anyone on an iitm.ac.in domain I don't have to go through the whole first-contact rigmarole (some of the subdomains are, sadly, a different story).
If you don't have a handy Big Tech email API lying around as a backup, you might begin to think: what's the point? Taking a step back, why selfhost at all if all your emails are going to end up at Big Tech inboxes anyway?
But here's the thing: if there's so many of us selfhosters having the same dilemma, perhaps we can at least email each other? I have no interest in setting up arbitrary barriers to people who want to contact me, and neither, presumably, do you.
So, to the selfhosters thinking of giving up and going to Big(ger) Email, I would say: do that if you must, but keep your small email around too.
It's the only way we can have the alternative email network—the truly open and decentralised one—up and ready.
It's also the place where we can figure out better, more inclusive ways of doing things. Spam is a serious problem, but it doesn't have to be Big Email who gets to decide how we handle it. As long as you have at least one other Small Email person to communicate with, your selfhosted server is serving an important purpose.
And if you don't have anyone at all to exchange Small Email with? I'm willing to be that first person.
DC25 network usage graphs. 
Flow diagrams. 
Streaming bandwidth graph. 
