Home / Blogs

Searching for Truth in DKIM: Part 2 of 5

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)

By J.D. Falk, Internet Standards and Governance

Filed Under


Not quite what ADSP means John Levine  –  Mar 13, 2009 3:10 PM

ADSP says (give or take some minor theological arguments currently underway) that all mail from foo.com is signed by d=foo.com, which suggests that mail without that signature is likely to be bogus.  It doesn’t say anything about other signatures; if a message is signed both by d=foo.com and by d=bar.com, that’s fine, and arguably if a message is only signed by bar.com and you have experience that tells you that all of bar’s signed mail is good, you might well accept it regardless of foo’s ADSP.

I think we agree that authentication and reputation are surprisingly subtle.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byDNIB.com