@cR0w@infosec.exchange @jerry@my-place.social
mostly yes but also no? My only disagreement is in the nuance of the motivations.
DMARC and SPF are definitely technologies that exist to protect the sending domain first, and the receiving domain second, but both sides of the email transfer have to have the enforcement turned on because DMARC and SPF are bolted on security extensions to a federated protocol that never envisioned such protections, and there are a lot of legitimate orgs that never put in the work to properly set up their DMARCrecords. There are some orgs (mainly government in my experience, but a dickhead with a chainsaw may have recently fucked that up) that actually do require the sending domain to have a valid DMARC record, but that is rare. IMO the reason that mass-market email platforms didn’t require DMARC for sending domains at its introduction was for compatibility with the remarkable plethora of legitimate orgs that didn’t have the resources to set it up. So I don’t think it was done that way in the first place for intentionally malicious reasons, but the email world definitely could agree to require DMARC for senders, let poorly managed domains deal with the fallout, and massively reduce spam problems. But it would come at an initial cost of mail delivery failure.
The current huge conflict of interest is definitely that the email world is dominated by big services that do big business by selling anti spam solutions, but it’s not because DMARC was designed to only protect the senders. It can be configured to protect receivers TODAY, if those receivers are willing to deal with mail delivery failures. They are currently taking advantage of the situation to sell fancy security product, and there’s no impetus for them to kill their golden goose.