As a side note, if you host your own authoritative nameservers (such as a very basic debian or centos + bind9 setup), you can set up your own self hosted gitlab and oxidized to retrieve the contents of /etc/bind/ on a cron job, put them into git and store them for revision control.

https://www.google.com/search?channel=fs&client=ubuntu&q=git...

I'm not familiar enough (or at all) with DKIM internals to know which side is broken, but I had a DKIM verifier extension on Thunderbird, which would verify either against a cached key or the current key.

One person who emails me rotates their keys often (weekly or so), and unless I read and verify it a day or two after it is sent, the verifier complains, and there's no way for me to know that the message is authentic. I have to trust my service provider that they did a timely DKIM verification, and I don't want to do that.

In my opinion that's not what DKIM was ever meant to do. Yes a email client can examine dkim headers and do something based on that. But it's much better used as a method for influencing a metric of spam or not spam on your MX smtpd that receives incoming traffic. Not as a guaranteed 100% "this is legit" indicator. It's a thing used to influence a weighting score on my postfix setup.

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.

Used as you suggest, there’s a good chance a fishing/scam email will go through since it only affects spam score.

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)

If it came from a fake "paypal.com" address but was not received from the MX for paypal.com, your incoming spam filtering has issues other than DKIM... Something like that would get 5+ extra points added to it by a basic spamassassin setup. With a common setup that is postfix + opendkim as a mail filter on the incoming, that should also get caught.

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.

I agree they did something wrong. But I don’t run my own server - and I do run my own 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.