DKIM is Done

This was posted to the IETF DKIM Working Group mailing list this morning:

The dkim working group has completed its primary charter items, and is officially closing. The mailing list will be retained for future discussions involving dkim. The list archive will also be retained.
The dkim working group was primarily focused on DomainKeys Identified Mail (DKIM) Signatures and DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617). We applaud the working group for progressing DomainKeys Identified Mail (DKIM) Signatures from proposed standard (RFC 4871) to Draft Standard (RFC 6376). The working group also produced the following Informational RFCs: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) (RFC 4868), DomainKeys Identified Mail (DKIM) Service Overview (RFC 5585), Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol (RFC 5016), and DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations (RFC 5863). The proposed standard DKIM And Mailing Lists (RFC 6737) was the final RFC produced by the working group.

What does this mean for DKIM-the-protocol?

DKIM as a protocol is finished and stable. It’s possible that there could be an incompatible “DKIM version 2” in the future, but it’s fairly unlikely. It’s also possible that there’ll be a clarification of the existing spec in the future, if someone flushes out some bugs or inconsistencies while they’re implementing it, but that won’t break any existing usage.
If you want to attach an identifier to mail you send, or you want to use those identifiers to handle whitelisting or reputation-tracking or to drive domain-based feedback loops for mail you receive, DKIM is the way to do it.
What’s left to do?
DomainKeys Must Go
DomainKeys was the forerunner to DKIM. It’s been obsolete for several years and at this point nobody should be signing with it (or paying any attention to DomainKeys signatures). I’ve seen several cases recently where attempting to support both DomainKeys and DKIM lead to operational problems with the DKIM signing. It’s dead, let it go.

Good operational practices for signing with DKIM
This is the big bit of work left to do. While verifying a DKIM message and extracting the d= identifier from it is very well-defined, how best to sign with DKIM – including how best to do key management, key delegation and what DKIM options to use when signing – still hasn’t crystallized. Our suggestions for that are here: www.dkimcore.org
Configuration API support in smarthosts
While messages can be signed with DKIM anywhere in the mail pipeline they’re almost always signed at the sender smarthost. Many of the smarthosts added DKIM support by evolving the code they already had to sign with DomainKeys, which was a good engineering decision at the time. But DKIM is a much more flexible protocol than DomainKeys was, yet I’m told some of the smarthosts haven’t evolved far enough and only really support a “DomainKeys-like subset” of DKIM. Limited APIs like that reduce your flexibility in how you deploy DKIM, and will mean you can’t even try some of the smarter ways to use it.
As a minimum, your smarthost should be able to sign a message with any arbitrary private key / d= value pair rather than being tied to any email address or domain in the email headers. If it can’t do that, it’s not really supporting DKIM. If it can sign a message twice or three times efficiently – while processing the body of the message just once – that’s a DKIM feature that’s likely to be useful for ESPs.
Some sort of API to allow key management automation (deployment, delegation, rotation and invalidation) would make rich DKIM use much easier to deploy at scale, but I don’t know if anyone has looked at that sort of support in smarthosts yet. Anyone know?
Semantics
There’s still some misunderstanding about what some elements of DKIM mean.
What is the identity that DKIM conveys? (Usually the “d=” field, though the additional information in the “i=” field might sometimes be part of that too).
What does the selector mean? (Absolutely nothing! If you try and claim it does, you’re doing it wrong. It’s intended for key rotation and key delegation, and attempting to use it for anything else will make key management harder, and likely end up making the signature less secure).
What do multiple signatures mean? (That it was signed by each of those domains. None is more important than the others, and there’s no “primary” signing domain. What you do with that information is a whole other thing, though).
What about ADSP?
ADSP is effectively dead. The discussions that happened as part of it’s development, and the results (both good and bad) of limited testing with it will probably lead to something with similar goals in the near future – more limited in scope, probably, but less fundamentally flawed.
Whence SPF?
SPF isn’t dead, by any means. I expect some mail recipients will check both DKIM and SPF for the near future (though I’ve heard some interesting discussion about receivers keeping a local cache of DKIM results correlated with sending IP which may end up replacing one common SPF-based performance hack).
And what’s next?
Thanks to everyone involved in the DKIM specification process for creating this unobtrusive, robust way of attaching an identity to an email!
It’s going to be interesting to see what features people build on top of the DKIM foundation.

Spear phishing
Are you ready for the next attack?

Related Posts

ESPs, Non-portable Reputation and Vendor Lock-in

I’ve seen some mentions recently of ESPs suggesting that if you use your own domain in the From: of mail you send through an ESP then that ESP can’t “do email authentication” properly unless they require you to edit your domains DNS settings. That’s not really so, but there is a kernel of truth in there.
The real situation is, unsurprisingly, a bit more complicated.
What authentication features should you look for in an ESP?

Read More

Gmail shows authentication data to the recipient

Yesterday Gmail rolled out some changes to their interface. One of the changes is that they are now showing end users authentication results in the user screen.
It’s really the next step in email authentication, showing the results to the end user.
So how does Google do this? Google is checking both SPF and DKIM. If mail is authenticated and the authentication matches the from address then they display the email as:
mail from steve to me
If we click on “details” for that message, we find more specific information.
full details of message showing signing domain and spf domainIn this case the mail went through our outgoing mailserver to gmail.
Mailed-by indicates that the message passed SPF and that the IP address is a valid source of mail from wordtothewise.com.
Signed-by shows the domain in the DKIM d=. In this case, we signed with the subdomain dt.wordtothewise.com. That’s what happens when you sign using the domain in the From address (or a subdomain of it).
For a lot of bulk senders, though, their mail is signed using their ESP’s domain instead.  In that case Gmail shows who signed the mail as well as the from address.

And when we click on “details” for that message we see:
3rd party signature detailsThis is an email from a sender using Madmimi as an ESP. Madmimi is handling both the SPF authentication and the DKIM authentication.
As an aside, this particular  sender has a high enough reputation that Gmail is offering me an unsubscribe option in their interface.
Gmail is distinguishing between first party and third party signatures in authentication. If the mail is authenticated, but the authentication appears to be handled by a separate entity, then Gmail is alerting recipients to that fact.
What does this mean for bulk senders?
For senders that are signing with a domain that matches their From: domain, there is no change. Recipients will not see any mention of your ESP in the headers.
However, if you are using an ESP that is signing your mail with a domain they own, then your recipients will see that information displayed in the email interface. If you don’t want this to be displayed by Gmail, then you will need to move to first party signing. Talk to your ESP about this. If they’re unsure of how to manage it, you can point them to DKIM Core for an Email Service Provider.
Gmail blogpost about the changes
Gmail help page about authentication results

Read More

A quick marketers guide to DKIM

J.D. Falk posted a brief but comprehensive guide to the different DKIM flags: what they mean and how they may affect delivery. (The original link seems to be dead so I reproduced the blog post for reference It’s just that good. A DKIM Primer Resurrected

Read More