My new view of DomainKeys
The way I choose to look at it is that for us, it is essentially a lightweight anti-tampering feature. We can sign outgoing messages to transparently add some basic integrity protection for our users' mail, and verify inbound DKIM signatures for a basic integrity check. This makes using it a lot like our existing habit of using TLS SMTP whenever possible, ie it does some good for frustrating bad people and basically no harm.
(We're not going be able to actually start using DKIM any time soon, because all of our mail servers are running Exim versions that are too old to have DKIM support. The inbound gateway is due to be upgraded soon since it's still running Ubuntu 6.06, but the mail submission machine is running RHEL 5 which is good for years yet. And supporting DKIM is in no way important enough to justify compiling a local version of Exim from source.)
The one fly in the ointment would be if people implementing DKIM checkers (whether in MTAs or MUAs) had made my mistake and are reading more into DKIM than is actually there, especially if they're treating it as a kind of SPF. In that case, adding DKIM DNS data and DKIM signatures to some of our outgoing email might harm the delivery prospects of email from us and our users that wasn't DKIM signed by us, as would happen for, eg, email that our users send from GMail using their CSLab addresses. Hopefully this is not the case.
(Making it harder for our users to use GMail would be, to put it one way, an extremely unpopular move.)
Sidebar: Where we would put DKIM in our incoming email flow
Our inbound spam and virus filtering can alter the message body (if
a virus is removed) and the
Subject: header (if a virus is removed
or spam is detected). My current opinion is that we should thus do
DKIM signature validation before spam and virus filtering, essentially
treating it as a validation of the message state before we started
mucking around with the message. I can justify this from a message
integrity view by saying that our alterations are automatically okay
(well, from our perspective).
(Logically this implies that we should re-sign messages when we forward them, but I'm not quite comfortable with that for various reasons.)
If we do DKIM validation after the filtering, all virus-cleaned messages
will fail DKIM checks and most spam-scored messages will (the
header is usually part of the signature). I don't think that that's
useful, whereas it could be somewhat useful to know if a spam or virus
message was altered in transit (or sent by a spammer that forged the
DKIM signature) or clearly came that way originally.