I am starting to see more and more requests regarding DomainKeys (DK) and Domain Keys Identified Mail (DKIM). Yesterday, I found a DKIM talk from Sendmail CSO, Eric Allman. The presentation starts off slow but eventually gets into some details of DK and DKIM.
Integrity
DK and DKIM is designed to solve the problem of integrity. When you receive an email how can you be certain of the origin of the email? DKIM solves this issue by using signing keys. When your server signs the email a recipient can then verify that the email is from you by using your public key. DKIM/DK uses the DNS system to publish public keys. You can watch the video for implementation details but at the surface the technology allows you to be sure of the origin of the email.
DKIM (alone) is not for Spam
There is a lot of confusion about DK/DKIM and its intent. DKIM is to allow recipients to be sure of the origin of the email and that the email has not been altered by a 3rd party. Standing alone, DKIM does nothing to impact spam, either sending or receiving spam.
Any spammer can setup a DKIM server, so simply letting signed messages through without filtering will not help combat spam. Currently, some ISPs, such as Yahoo! and Gmail, have started using DK/DKIM technologies in their spam filtering processes. But this is not a anti-spam solution. The reason this helps now is that few spammers bother with DKIM. They can get their message out without it. As the percentage of spammers using DKIM increase, the technology will cease to be effective as an anti-spam measure.
DKIM can help with spoofing and phishing. If you get a signed email from paypal.com, you can use the paypal.com public key to verify the origin of the message. If it does not verify, then you can decide how to treat the message.
At the surface, DKIM simply gives the receiver more information about the message. The receiver can then implement other tools to decided what to do with this information.
DKIM with Reputation = Anti-Spam
If you combine DKIM with a reputation or trust system, then you can start developing an anti-spam framework. For example, Sender Score Certified provides a reputation monitoring service. They verify that the sender has good email practices.
Using a reputation service can allow you to accept emails with little scanning. If the email has a valid DKIM signature, you know the message is authentic. If the email sender has a good reputation, then you may not treat it as spam.
Should you use DKIM?
I would only consider using DKIM if you are absolutely certain that the sender has good email practices. DKIM will pose a major challenge to shared hosting providers. Often, you may not know if your client is using good mail practices or not. Are their scripts secure? The last thing you want is signed spam – which will ruing your sending reputation.
Aside from the business/policy questions, there is also the technical issue. If you are using a shared hosting control panel like Ensim or cPanel, DKIM implementation may not be advisable. Plesk recently introduced DKIM in version 8.4.
If you are running a large mailing lists or email marketing campaign, then you may want to start considering DKIM. If you send any large quantities of email (>1000 per day), then you may want to consider a dedicated email system. I always recommend isolating any mass-emailing from your corporate email server or web site. You don’t want your main email IP to end up on a blacklist.
Check out the video. You need to have some basic background in DKIM, identified email, and signing technologies, but it is one of the better presentations I have seen.
DK and SenderID
Domain Keys and SenderID are related but independent of DKIM. SenderID or SPF is a DNS based technology that can be implemented on any domain with software modifications. DK is like DKIM in that it also tags emails. Most email software has to be modified by support DKIM or DK.