It's pretty simple with a couple concepts. If Alice and Bob each have a public/private key pair, they can do a diffie-hellman key exchange to form a common sec

It's pretty simple with a couple concepts. If Alice and Bob each have a public/private key pair, they can do a diffie-hellman key exchange to form a common secret. If they use that secret to authenticate a message, then it can be shown that only Alice or Bob sent the message. If you're Alice or Bob, this is what you want to know --- either you or your corespondent sent it, and if you didn't send it, your correspondent did. But if Alice or Bob asks Carol to validate it, Carol can only determine that Alice or Bob sent it, and perhaps not even that. Anyone in possession of the secret used to authenticate the message can also make a message that would be deemed authentic. If you have participation of Alice or Bob, you can show that the secret was derived from DHE with Alice and Bob's key pairs, but that's all. This is nifty and useful, but it's more appropriate for end to end communication, which is not the domain of DKIM. Email is a multi point store and forward system, where each point would like to know if a message is authentic; deniability like this would probably mean either a) only the final destination could determine authenticity and therefore intermediates would not be able to use authenticity as a signal to reject mail b) only the first intermediate could determine authenticity; it could be used to reject mail, but the end user would have to trust the intermediate Both of these are workable systems, but DKIM provides that all intermediates and the end user can know the mail was authorized (to some degree) by the origin system.