Spam definitely is a fundamental problem of all open-inbox systems like email.
To my knowledge, these systems are proprietary, obscure secret sauce heuristics. My point is that we should find a way to do spam prevention in an open and easy to implement way. Such an algorithm could then be applied to any open-inbox system, not just email.
How is a malicious actor going to set up a fake SPF record for my domain without compromising my DNS account?
It makes sense to block a domain even with a correct SPF record. It makes no sense to block an IP with a correct SPF record for a domain that you already trust. And, like I said, I'm getting bounced mail from people I've been corresponding with for years, so I know the recipient email providers do trust the domain. They're just being stupid with IP black listing.
That said, DMARC aggregate reports are not supposed to be human readable. You don't want to set the reporting endpoint to your personal inbox. You need a DMARC aggregation tool, such as included in https://www.mailhardener.com to process them. (full disclosure: I work there)
I guess generally speaking, federation works well for DNS itself but not so well for email, since the malicious stuff you can do with DNS is greatly limited. Abuse/spam is everywhere, not just email, and the sad part is that providers not only went and rolled their own anti abuse systems, but they also went to great lengths to keep them secret.
Without solving the spam problem, we won’t see decentralized or even federated systems widely popularized for any products which has these incentives. This includes mastodon, Nostr etc. The worst part is that projects can become pretty big before the spam starts, so it kills projects at the worst possible time. I wish the FOSS community came together and focused on finding solutions that work, because decent abuse prevention today is neither easy nor cheap to get right. And going without one is a ticking time bomb.