Now that we understand how digital signatures work, let's take a look at DomainKeys.  Like SPF and SenderID, DomainKeys is a mechanism of sender authentication.

DomainKeys uses public key encryption to authenticate messages.  It works in the following way (much of this is based upon Yahoo's description):

1. The owner of the domain generates a pair of keys, a public key and a private key.  The public key is published in DNS, the private key stays under control of the domain owner.  This private key is made available to outbound SMTP mailers.
   
   
2. When a sender wishes to transmit a message, the outbound mailer uses the private key to generate a digital signature.  This digital signature is inserted into the message headers.  The email continues on its merry old way, the same as any other message in a non-DomainKeys compliant domain.
   • Briefly speaking (we will correct this in a future post, I am sacrificing accuracy for brevity), this digital signature is generated by combining the message content and some of the email headers, and then using the private key to generate a hash.
     
3. The signed message arrives at the recipient's email server.  The recipient email server extracts the domain from the From: address (not the envelope sender), the digital signature and then retrieves the public key of the domain from DNS.
   
   
4. The receiving email server uses the public key to verify that the digital signature was generated by the matching private key belonging to the domain in the From: address.  If so, it means that the message was sent by the originating domain in the From: address and the message content was not altered in transit.
   
   
5. Once authenticated (or not), the receiving email server has a number of options at its disposal. 
   • It can continue to filter the message using content filtering
   • It can bypass filtering if it is on a safe-senders list
   • It can add "reputation points." 
     
     If the message fails authentication, that is, if the digital signature does not verify the sender:
     
     
   • It means that the claimed From: address (probably) did not send the message or it was altered in transit.  The message can be filtered more aggressively, deleted, or automatically quarantined.  This would be analogous behaviour of an SPF Hard Fail.
     
     If the domain always signs its outbound mail, the message doesn't have a signature and the receiving email server sees the mismatch:
     
     
   • It means that the message (probably) did not originate from the claimed From: domain.  The message can be filtered more aggressively, deleted or automatically quarantined.  Like a signature verification failure, this would be similar to an SPF Hard Fail.
     

 We can see that DomainKeys is similar to SenderID in term of authentication.  If differs from SPF in that it protects the From: address, just like SenderID.  To combat spam and phishing/spoofing, there are two ways as I describe above, plus the reputation system:

1. The authentication failure of a message with a digital signature implies that the DomainKeys header is fake.
   
2. If a message arrives from a domain that always signs its mail and doesn't have a DomainKeys header, then the message is likely spoofed.
   
3. Domains that do sign their mail and are authenticated have a reputation system built around it.  If a spammer always sign their mail and have a poor reputation, mail originating from those domains can be blocked at the connection level without going through spam filtering.

I have one more comment with regards to the Frequently Asked Questions section of the DomainKeys link on Yahoo's page.

---

I don't use my domain's SMTP server to send email.  How do I use DomainKeys?

---

The page has a few workarounds, none of which are great (SenderID and SPF have the same problems), but the fourth bullet point is the following:

---

Finally, you could choose to send unauthenticated mail. While this will not be a good long term strategy, it will certainly take quite a while before the vast majority of Internet email is authenticated. If you choose this path, you should carefully monitor the amount of authenticated mail over time to ensure that this strategy does not impact the deliverability of your email.

---

I'm not a big fan of this option.  I'm reading through Bill Gates's book Business @ The Speed Of Thought, and one of the points he makes is that once you introduce a new system, you need to deploy it company wide and remove the old system (once the new system works -- assume that it works better).  If you give users the option to fall back to the old version, they will fall back to the old version because it's easier (at least it is initially for people), more familiar, etc.  The newer, better system will never reach full deployment and you'll forever be supporting two systems.  Then, if you deploy a new system later on, there will be three versions you have to support!  Gates's point is that once you get a new system implemented, you have to "force" your users to use it and take the plunge and there is no going back.  (Please -- no comments about how Microsoft forces people to do stuff).

I see this option of choosing to send unauthenticated mail as providing domain owners the option of doing something we'd rather not see them do.  If we give domain owners the option of not signing mail, they will fall back to the old version and not sign their mail.  A slippery slope, indeed.