just for the record, while I mostly agree with the analysis on that page, I believe the author tries to make a stronger case than it really is.

1) DKIM verifies the To: header, not the "rcpt to" receipient. The To: header has no value in determining who actually received the email. (Ex: you receive the email via BCC, you can't verify that the recipients listed in the To: actually got the email).

2) GMail actually does let users "spoof" the From: line. it needs cooperation from the "owner" of the address you want to use in the From line, but it is possible, and once set once, is never reconfirmed.

so, as I said, while I generally agree with the analysis, but I think 2 statements it makes are a bit too strong

1) "it was sent from this specific account, [email protected]" - It could have been sent via a different account that got the specific account's permission (either via a hack of sorts or cooperation) to spoof it. I'd agree that this isn't that likely.

2) "the intended recipient was to the account [email protected]" - all we can know is that this was the To: line, it is very easy to spoof this. (every email one gets via BCC is essentially spoofing this).

do I think either points are very likely? Not so much, but any page trying to prove the authenticity needs to address the limits of the analysis, which the author didn't do.

Of course there are other assumptions we make, notably that no one was able to steal or crack Google's old DKIM key. I wonder how many google employees would have had access to this DKIM key over time (and if security procedures might have been relaxed once it was "expired" and the public portion no longer distributed).

DMARC does a decent job of solving a few of those points. Alas, that only proves the point that another commenter made about server-to-server SMTP being a hack-job piled on top of another hack job.

The one thing DKIM is good at is for protecting the From-header and body from modification, allowing receiving servers to verify that the sender is genuine whenever they receive an incoming message (when combined with DMARC that is). For anything else, use PGP, S/MIME, or something else that actually does end-to-end encryption/signing.

Purely from an engineering perspective, in a setting where we care about privacy --- ostensibly, email is one of the settings where we care most about privacy --- the ability of a stranger to authenticate any particular historical email is a fairly grave vulnerability. Privacy-preserving systems go out of their way not to have it.

You may have some kind of public policy or archaeological argument in favor of the vulnerability, but then it's hard to see how the same argument doesn't suggest we should compromise the entire confidentiality of every email; after all, that would make research a lot easier.