In part 1, we explained that the DKIM “d=” value identifies the domain name which signed the message, which may be a different domain name from the author of the message.

Tying the signing and author domains together will require an additional standard: Author Domain Signing Practices (ADSP). In IETF parlance, the “author domain” is the domain name in the From: header, so ADSP is a way for the author domain to publish a statement specifying whether any other domain name should ever sign a message purporting to be From: that author domain.

So with ADSP, Return Path (my employer) could publish a policy stating that only returnpath.net will ever sign messages from returnpath.net—in other words, valid messages From: addresses @returnpath.net will only have DKIM signatures signed by (d=) returnpath.net. Anyone receiving a message with a different d= value would be likely to reject it, or view it suspiciously.

For some domains, such as banks and other common phishing targets that carefully control who sends mail on their behalf, a strong ADSP statement is imperative to prevent spoofing and fraud. For others, such as ISPs or corporate domains with a lot of Blackberry users who relay mail through their mobile provider’s SMTP servers, ADSP probably isn’t a good idea. But that’s okay, because it’s optional.

ADSP isn’t required to determine whether to trust a message. An untrustworthy domain could make a strong ADSP assertion as easily as a trustworthy domain. But when a trustworthy domain says “don’t trust messages that look like they are from me unless I sign them,” that provides a level of security which has never before been possible in email.

There isn’t currently any way for the author domain to say “oh, by the way, you can also trust messages that look like they’re from me if they’re signed by my friend over here”—where the “friend” is an ESP, or a similar service. This is often called “third party signing.”

It would be fairly easy (from a standards perspective) for an author domain to hand over a special key (designated by a selector, the s= value) so that their ESP can sign as the author domain, saying “trust this signer as if they were me”—because from a DKIM verification perspective, it is them. ADSP still works. The author domain can even revoke that key, rendering it invalid, whenever they please.

In part 3, we’ll dive deeper into the concept of “trust” as it applies to DKIM.

(This article was originally published by Return Path)