I’ve had several scam emails, including from @paypal addresses, which did pass my mail service’s filter, but flagged by the DKIM verifier.
I want defense in depth; I’m ok with the occasional visible false warning. Rotating DKIM keys often makes it unusable on the mail client. (Not sure that’s a problem with DKIMs intended use, but if keys are rotated slowly enough - e.g. once a month - it’s usable for that too)
I guess the point I was trying to make is that DKIM was really intended to be deployed on the service-provider side, and smtpd mail filtering side, rather than on the client.
And it’s not the MX that says where mail comes from, it’s the SPF record (if you have one).
Google had, for a very long time, an issue where any g-suite/gmail user could SPF as any g-suite domain; so servers that didn’t check DKIM (most until recently, and probably still) would let it through happily.
Note that there is not a lot of technical barrier preventing a spammer from setting up a very basic opendkim daemon and key, and using a one time throwaway domain name to spam from, along with the appropriate dkim records in the DNS zonefile. But it's a barrier that not a lot want to jump through.