There are many who would like to not be beholden to anyone else for their own email, but when they try it, they quickly find it's far too much work to actually ensure that when they send an email to, say, apply for a job, it will certainly arrive.
I think not knowing is a big problem. For example, I just use docker-mailserver on a VPS with decent IP reputation and SPF set up (but not DKIM/DMARC) and haven't really had any issues with the big providers.
However, if there were issues, I wouldn't know about those myself, unless I had some code that sends emails to those providers and then checks whether they've been received periodically.
On one hand, it would be nice to have confirmation for when a mail has been handled successfully (delivered and sitting in their inbox folder, not tossed aside and not filtered as spam, regardless of whether they'll actually read it), but then again some software will also block remote content (like tracking pixels) over justified privacy concerns and bad actors would also benefit from said functionality.
That's really small amount per month but for 100K a day you can use almost any extremely low-end VPS
But it also feels like fewer and fewer people are running their own mail servers. Everyone seems to just outsource it to Google or Microsoft. I'm also surprised at how many engineers barely understand how email works. (IE: I have to show them what email headers are and the useful info that can ne found there.)
I love to throw out a library and implement something myself so I gain a better understanding of what’s going on and maybe even improve on what was there before. But I can’t do that with email. Other servers are going to accept or reject my mail solely based on what my IP is, irrespective of how good my implementation is or is not. I’ve just never found it worth the time to dig into.
I uses to use this solution until a few months ago when I decided that self hosting my mail server was too much work. To be fair, it's not Chasquid's fault as operations there are basically 0, but more of a spam / email reputation thing.
Even if you don't ever SPAM and send like one email a day on average, you won't be able to get them delivered to the recipient's inbox.
You can use SPF, DKIM, DMARC all you want, google won't care.
The killer problem is often source address, and source address range, reputation. Mail sent from a normal residential ISP will have trouble. Addresses allocated by many VPS providers (and some dedicated server providers) will have spotty reputation. Mail from cheap VPS providers simply won't get through (many block SMTP outgoing and state so on sign-up because they don't want the support burden of people complaining about this). Sending mail from cloud providers can be an issue too (I've had mixed results with VMs in Azure sending out alerts).
If you are stuck with such a source reputation issue then you can use a service like MXRoute (several others are available, this one I've not used but it seems popular on a couple of hosting forums I frequent) as a relay. Obviously that is not free, but it is cheaper than moving to a much more expensive VPS provider or changing your home ISP.
Another reputation issue many have when setting up a new project is that many mail servers explicitly distrust new domains. In this case SPF, DKIM, and a good reputation source address won't make much difference. The definition of “new” varies from place to place but where it is an issue you need a domain registered at least some months ago. This can be mitigated somewhat by users explicitly marking messages from new domains as not spam, but that is not something you can rely upon as said users need to see the message to be able to mark it that way.
If you have DKIM,DMARC,SPF and the reverse DNS of the mailserver is set to the correct domain you have no problem. Well.. except for GMX and yahoo which frequently block me for a few hours when multiple parents register at the same time
https://github.com/mlhpdx/email-delivery
It’s industrial strength in some respects, but not for those wanting an e-mail UX.
