IMO, there are limitless other things I'd rather be doing than these!
The problem is that you need a lot more volume to be able to use the feedback loop mechanisms ( https://blog.returnpath.com/what-is-a-feedback-loop/ ) efficiently.
Sure, it all works, but it's still the old piece of shit SMTP wild wild west, because when it stops working, you can do nothing. (But usually going to the saloon, having a rough night and waiting will solve things.)
Observe how few of the major sites are DNSSEC-signed. In reality the only purpose signing has is allowing your site to vanish from view of the few DNS resolvers dumb enough to do DNSSEC validation.
I figured that it would be, but trying to set it up was the single most frustrating thing I've ever experienced running a Linux box, and I never did get anything properly working after many days of trying. The principles seemed straightforward enough and there was plenty of software available, but what I really wanted was to self-host the mail store and IMAP server but send/receive via ISPs or other services who are better at administering a full-time SMTP setup than I am, and somehow I just never could find the magic incantations in the settings files to make that go. :-(
For inbound, you'd presumably want the server using fetchmail or getmail to then push them into your local mailboxes. Should be plenty of documentation on those projects.
Given that fundamentally neither email protocols nor mail store structure on a typical Linux box are particularly complicated, and that all of the software I was using was well established and reputable, it was an exceptionally frustrating experience. Someone with more skill than me would surely have installed the relevant half dozen or so packages from the distro, edited a few configuration files to set up the remote mail server details and identify the local processes to each other, and had everything working within a few minutes. Unfortunately, without that knowledge the sheer number of options and possibilities was overwhelming and I never got that far. What I really needed was a one-page HOWTO for the most simple use case and a setting for each package that said "don't try to do anything clever or unusual", but what I had at the time was literally hundreds of screens' worth of detailed parameters and config file options, each written according to the conventions and assumptions of their own package.