The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.
The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.
Which is only the core problem because dmarc fixed the other core problem of figuring out who the given sender is.
DMARC does not solve everything, but it does make other solutions more effective.
DNS SPF record: mydomain.io. TXT "v=spf1 -all"
DNS DMARC: _dmarc.mydomain.io. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
That ought to stop anyone trying to use your domains as source.
If you decide to think about this, you will quickly realize that email is f*ked and needs to be forked. Perhaps we need a Community Email Initiative that blocks corporations and only allows Community members.
Trust is the one thing you can't buy on the Corporate Internet.
I am sure many people will be offended and down vote this comment because they cannot conceptualize an internet without Corporations.
There is so much crossover between personal email and corporate email.
Depending on how hard you want to make it, you can slap all the parts together yourself or use something like Zimbra, Mailcow, iRedMail, mail-in-a-box.
The advantage over a fork, whatever specifically that means, is any service that needs E-mail as an identity verification, still works.
The big companies do not have to care because nobody will block Google, Microsoft or Amazon. They are too big to fail.
Spoofing a From field is an insignificant problem in comparison.
I even go to the trouble of registering in their Postmaster Tools and clogging up my DNS with their verification tokens all for the tools to tell me I don't send enough mail while they happily pass what little mail I send straight to spam.
Not enough outgoing email
You haven't sent enough email to personal Gmail (@gmail.com) accounts to determine deliverability status for your domain and messages.
Guess it doesn't help that as I look today the Postmaster Tools dashboard shows "Last updated Sun, Apr 26, at 9:30 AM."
Then on the other hand Google can flood me with spam filled Google Calendar Invites and Google Drive Share notifications, all fully DKIM signed because they are coming out of those services, all day long.
Microsoft have also recently changed their Smart Network Data Service (SNDS) so now only my cloud provider can access the console as they only allow verification to the owner of the whole ASN block you're under. I can't access detail about my domain anymore, and still my mail goes to junk. Unless you own a chunk of IPv4 ASN range you're out of luck. IPv6? Nope, not at Microsoft. "Please note that IPv6 is not currently supported." [1]
[1]: https://substrate.office.com/ip-domain-management-snds/SNDS/...
Some mail providers will junk your mail if you don't have a reject/quarantine DMARC policy because you're seen as enabling the spammers so everything out of your domain must be punished.
Anyways, the new CF AI tool is relatively decent for this purpose, explains the fact that most warnings in CF are harmless, but the lack of standardized guidelines is annoying to say the least.
https://utcc.utoronto.ca/~cks/space/blog/spam/DMARCPractical...
For example, gmail.com treats unauthenticated email as spam implicitly, regardless of DMARC policy.
The report that they send you is useful for you to make sure your emails that you expect to go through are going through.
SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.
Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.