d= for data

A few ISPs use the d= value in the DKIM signature as a way to provide FBL and reputation data to senders. This has some good bits, in that senders can get FBLs and other information regardless of the IP address they’re using and whether or not they have sole access to it.

There are also some challenges with using the d= as a data identifier. One of them is that ESPs may not be able to get a full picture of what their overall customer base is doing if their customers are signing with their own d= value.

Some ESPs have solved this by adding two DKIM signatures to the email. The first signature is with their own d= value, one that is shared across all their customers. The second is with the individual d= for that particular customer.

There are a couple questions that regularly come up when I discuss double DKIM signing with folks. One of them is how much weight is given to the shared DKIM signature? There is some, but if the domains are signed in the correct order, the ESP domain seems to fade into the background of reputation.

Another question of the questions related to double DKIM signing is will signing twice reveal information about the sending infrastructure to the receivers or the end users. The answer to this is not in the vast majority of cases. Most ESPs provide IP addresses for their customers to use. These IPs are identified as belonging to the ESP and ownership can be determined using standard tools. While many end users probably may not be able to easily figure out who the ESP is experts and ISPs can.

But what happens for ESPs that use one of the API based providers? For instance, an ESP that uses Sendgrid or Amazon SES may want to allow customers to sign with their own d= but also monitor all their customers. In this case, they should be able to sign with their own shared d= before handing the message off to the ESP. The ESP can then sign with their own key and then, finally, sign with the customer specific key.

There is theoretically no limit to the number of DKIM signatures you can add to a message. You just need to be careful about which of the headers you sign, to avoid having them altered during future steps. Of course in practice there are unlikely to be cases where quadruple DKIM signing is necessary. But I say that now and someone will point out a case where it makes sense.

In any case, there are no technical reasons to limit DKIM signatures to one or two. This is very helpful for those cases where DKIM is being used in ways unrelated to reputation.