DomainKeys Identified Mail, or DKIM as it is more commonly known, is almost 20 years old. The original spec was published as an RFC in 2007, a milestone in the battle against spoofing that bolted a cryptographic identifier onto email to prove a message had not been altered in flight. Effective as DKIM was, it was never perfect, so the industry has circled the wagons again to build a more robust version of it.
So what is DKIM?
Put simply, DKIM is a public/private key pair that adds a digital signature to outbound email. The signature is not unlike a proof of authenticity, and it prevents tampering with the content in flight. Along with SPF, DKIM is a foundational component of DMARC (Domain-based Message Authentication, Reporting and Conformance) policies, which let a sender instruct a mailbox provider what to do with messages that fail an SPF or DKIM check, or both.
Why do we need DKIM?
Email is the first and original digital communication method of the internet. When it was created, the internet was a network used solely by researchers and the military, and back then it was called ARPANET, the Advanced Research Projects Agency Network. Email was a trusted communication method because everyone knew each other and implicitly trusted one another. That was so 1971, the year email was born.
Flash forward 55 years and email is the most used and most foundational channel of communication we have. Email security, however, has not necessarily kept pace with that growth. Adoption skyrocketed in the 90s with the advent of HTML email. Everyone who plugged into the then dial-up net and early broadband, which cost a fortune, got an email address. Once that happened, bad actors saw the opportunity in exploiting a channel that had no inherent authentication or security.
The industry set to work on the authentication challenge and created SPF, then DKIM, to tackle spoofing and the rising problem of phishing. DMARC came later and builds on both.
Why do we need DKIM2?
As effective as DKIM was at proving an email came from a specific domain and had not been altered in flight, it was not perfect. Bad actors found a way to exploit the standard through what is known as a DKIM replay attack.
The gap is that a DKIM signature covers the message headers and body, but not the envelope recipient. An attacker signs up for an account at a reputable domain and mails themselves a single message. That message arrives with a valid signature from a domain with good reputation. Nothing in the signature says who the message was for, so the attacker can take that one message and send the same signed bytes to millions of other people. Every copy still authenticates as the reputable domain, and that domain's reputation absorbs the damage.
Forwarding was the other gap in the original spec. Mailing lists and various tools forward messages and append footers or rewrite subject lines on the way through. Changing the body or a signed header breaks the signature, and the message fails downstream checks even though nothing malicious happened.
DKIM2 fixes both by establishing a chain of custody across every hop the message
takes. Signatures carry the envelope sender and recipient, in mf= and rt=
fields, so a message signed for one recipient cannot be replayed at scale to
everybody else. Timestamps are mandatory, so old signatures stop being worth
anything. And intermediaries record what they changed in an m= field, which
means a verifier can undo a mailing list's footer and check the original
signature instead of simply failing it. On top of the chain of custody, DKIM2
provides granular reporting at every step of the delivery process.
Where is DKIM2 today?
The standard is being developed at the IETF, and the mailbox providers are not watching from the sidelines. The specification is co-authored by Richard Clayton at Yahoo, Wei Chuang at Google, and Bron Gondwana at Fastmail. When the three of them are writing it together, the direction of travel is not really in question.
DKIM2 is not a finished standard. It is an active Internet-Draft, currently at revision 06, and there is no RFC yet. Nothing signs DKIM2 in production today.
If we have learned anything from the past, it is that email authentication and security efforts are accelerating, with the large providers pushing for more security in the channel. In late 2023 Gmail announced that DMARC would become part of its bulk sender guidelines. In February 2024 it became a requirement for anyone sending more than 5,000 messages a day to Gmail recipients. In the words of Ferris Bueller, if you do not stop and look around once in a while, you could miss it.
What do you need to do today?
As of this moment, nothing.
If the mere idea of email becoming more secure excites you, though, surf on over to dkim2.com and test against the live implementations running there. Several independent implementations across Go, Rust, Python, Perl, and C now interoperate, and the demo host will reflect your message back through transformations, mailing lists, and bounce scenarios so you can watch DKIM2 behave end to end. A number of different groups are building tools and running interop tests to lay the groundwork for what will eventually become the next evolution of email authentication at scale.
Have questions about email authentication? We would love to hear from you. Drop us a line.