DKIM for the impatient

I joined Genius.com a few months ago as a member of their Deliverability and Anti-Abuse team. My focus is on deliverability and managing the email servers. Genius has a great application that gets marketers and sales people working together. The Genius application relies heavily on emails being sent to the right people at the right time.

In addition to email deliverability, I have a background in system admin, programming (among other nerdy pursuits) and I am active in the technical (and sometimes political) Internet community which helps me in the world of deliverability . I look forward to sharing my experience with you over the coming weeks.

The world of DKIM: Domain Keys Identified Mail.

One of the challenges in identifying suspicious email is knowing reliably where it came from. With email coming from a wide variety of machines, it’s possible that a machine has been compromised and a malicious sender is spoofing mail headers, injecting false headers and essentially misrepresenting a third party. A lot of spam is generated by compromised machines which are part of botnets, networks of thousands (even millions) of remotely controlled machines. Some of these machines can be even legitimate mail servers, some can send email via ISP or ESP mail servers (ISP: Internet Service Provider, ESP: Email service provider). How do we know who is who? Who should we complain to? Some services like spamcop.net, try to analyse emails headers and figure out who was responsible for sending the email but they often also target whoever is managing the networks used to relay the emails. They aim wide, to ensure they will alert someone that will care and fix the spam source.

Would it not be easier to know who is sending emails?

There are some old techniques like Pretty Good Privacy (PGP) and S/MIME but they are heavy to implement because they require the cooperation of all of the users. Besides, we often do not need to authenticate the emails, but have a way to validate where the email is coming from. That is, to identify which system administrator configured the mail server that sent the email. This is the person we want to talk to for any problem. Hopefully he/she is a little bit more clued than the user who sent the email and can take remedial methods. Fixing problems on the Internet involves often finding the person that understands what you want and knows what action to take. End users are rarely in this category, but systems and network administrators are.

Several industry groups tried to solve this problem, the two main technologies that emerged were DomainKeys and Sender Policy Framework (SPF).

Ideally, emerging technologies will evolve to become standards. The Internet Engineering Task Force (IETF) does not generally create new Internet technologies, but they are very good at taking something that a group submits for standardization and making it rock solid because the peer review is strong. This has been the case for example for http (the web protocol), ssl/tls (securing connections between applications) and many others.

They did the same thing with DomainKeys and SPF and issued the DKIM specification. DKIM is now in the Internet Standard track of the IETF. It means if you like it you have a fixed specification you can follow that will work with various and disparate systems. It really become a de-facto standard when a large group implements it.

The main problem with SPF (and a bit with the Sender-ID upgrade) is that emails move from machines to machines before reaching the final destination. In many cases there are only two mail servers involved. The sender and the receiver. SPF inserts a header that tells if you check this domain, it will tell you that this IP address (of the sender) is authorised to send emails for this domain. But if you add a mail relay server, the whole scheme falls flat, as the receiver will have the ip of the mail relay not of the original server. On the other hand DomainKeys has another problem, it can only validate headers that contains the same domain name as the signature. So for instance you can relay a signed message but you cannot sign a message that you relay (like for a mailing list).

DKIM solves all these issues.

At the moment the DKIM Working Group at the IETF is working on specifying a standard for defining policies for the use of DKIM. But first you noticed, I did not say that DKIM authenticates an email, as it is not true. It just validates some headers. It is up to the receiver to process the email based on the successful validation of certain headers and deliver it to your inbox, junk folder, etc. DKIM allows a mail admin (or rather a mail server) to take responsibility for sending/forwarding an email and let other servers know.

This is convenient for instance, to build reputation based on who takes responsibility for sending/forwarding the email. For instance AOL has announced that they will move from IP based reputation to Domain based reputation using DKIM. Similarly, Yahoo provides a feedback loop based on the domain validating the email using DKIM. It does not matter which IP the email comes from.

But what are DKIM policies?

For instance, e-Bay and Google have announced that all the e-Bay emails will be DKIM validated and that Google will use this information to trash any email supposedly from e-Bay which is not DKIM validated. Imagine if all the banks were following this policy. It would seriously reduce the amount of phishing.

Third party validation.

I spoke earlier, that a relay mail server can validate an email. For instance in the case of mailing lists. The mailing list software receives an email, and decides to use its reputation to forward the email to all the subscribers. It can do a third party validation on an email it is forwarding. There is no requirement that any headers in the email (From, Sender, …) contain the same domain name as the domain name of the mailing list. This opens other possibilities. Let's take the bank example, instead of each bank having their own DKIM validation, they could also have a validation done by a bank confederation, authority or regulator (third party). This would add another level of reputation on the email (while they can still add their own DKIM validation to the email).

Genius is providing third party validation on all our customers’ emails. We are taking responsibility for the emails we send on behalf of our customers by ensuring they are DKIM authenticated. There is no silver bullet in ensuring a high rate of email deliverability and DKIM is just one of the layers that help deliverability from a technical perspective. The Genius Email Deliverability and Abuse team in addition to DKIM ensures high rates of deliverability through close and proactive management of its customers email campaigns, education and best practices.

PS: feel free to contact me with comments and suggestions and email delivery related topics you'd be interested in learning more about.

Last 5 posts by Franck Martin

• Verizon to use port 587 for mail submission - February 25th, 2009