DKIM implementation survey: prelim results

First off, I want to thank everyone who participated in the DKIM implementation survey. This week has been pretty hectic so far, so I haven’t had a chance to actually dig down into the data from the survey, but I thought I’d post some preliminary results.
The ESP survey had 45 respondents. 30% of those sent more than 15 million emails a month.
Of all the respondents: 40% are signing with Domain Keys, 51.1% are signing with DKIM.
Of all respondents: 79.5% are signing with Domain Keys and 78.8% are signing with DKIM to access services (whitelists or FBLs) provided by the ISPs.
50% of those not signing with Domain Keys are not doing so because customers have not requested it.  61% of those not signing with DKIM are not doing it because of technical difficulties with deployment.
The ISP survey had 16 respondents, with 37.5% handling less than 500,000 mailboxes and 18.8% handling more than 15 million mailboxes. 75% of respondents said they are not checking Domain Keys on inbound mail. 56% said they are not currently checking DKIM on inbound mail.
Only 10 ISPs answered the question if they plan to check either Domain Keys or DKIM.

  • 1 said they planned to check Domain Keys only
  • 3 said they plan to check DKIM only
  • 3 said they plan to check both
  • 3 said they plan to check neither

On a first pass it appears the ESPs are adopting domain authentication more aggressively than ISPs. It also appears one of the major driving factors in adoption was the Yahoo FBL being tied to DK/DKIM signed email.
Again, thank all of you for participating. I’ll have a more comprehensive analysis soon.

Related Posts

AOL and DKIM

Yesterday, on an ESPC call, Mike Adkins of AOL announced upcoming changes to the AOL reputation system. As part of these changes, AOL will be checking DKIM on the inbound. Best estimates are that this will be deployed in the first half of 2009, possibly in Q1. This is something AOL has been hinting at for most of 2008.
As part of this, AOL has deployed an address where any sender can check the validity of a DKIM signature against the AOL DKIM implementation. To check a signature, send an email to any address at dkimtest.aol.com.
I have done a couple of tests, from a domain not signing with either DK or DKIM, from a domain signing with DK and from a domain signing with both DK and DKIM. In all cases, the mail is rejected by AOL. The specific rejection messages are different, however.
Unsighng domain: host dkimtest-d01.mx.aol.com[205.188.103.106] said: 554-ERROR: No DKIM header found 554 TRANSACTION FAILED (in reply to
end of DATA command)
DK signing domain: “205.188.103.106 failed after I sent the message.
Remote host said: 554-ERROR: No DKIM header found
554 TRANSACTION FAILED”
DK/DKIM signing domain: “We tried to delivery your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554-PASS: DKIM authentication verified
554 TRANSACTION FAILED (state 18).”
As you can see, in all cases mail is rejected from that address. However, when there is a valid DKIM signature, the failure message is “554-PASS.”
As I have been recommending for months now, all senders should be planning to sign with DKIM early in 2009. AOL’s announcement that they will be using DKIM signatures as part of their reputation scoring system is just one more reason to do so.

Read More

Predictions for 2008

I did not have a lot of predictions for what will happen with email at the beginning of the year so I did not do a traditional beginning of the year post. Over the last 3 – 4 weeks, though, I have noticed some things that I think show where the industry is going.
Authentication. In January two announcements happened that lead me to believe most legitimate mail will be DK/DKIM signed by the end of the year. AOTA announced that approximately 50% of all email was currently authenticated. They did not separate out SPF/SenderID authentication from DK/DKIM authentication, but this still suggests email authentication is being widely adopted. AOL announced they will be checking DKIM on their inbound mail. I expect more and more email will be DKIM signed in response to this announcement.
Filtering. The end of 2007 marked a steady uptick in mail being filtered or blocked by recipient domains. I expect this trend to continue throughout 2008. Recipient domains are rolling out new technology to measure complaints, evaluate reputation and monitor unwanted email in ways that tease out the bad actors from the good. This means more bad and borderline email will be blocked. Over the short term, I expect to see more good email blocked, too, but expect this will resolve itself by Q2/Q3.
Sender Improvements. As the ISPs get better at filtering, I expect that many borderline senders will discover they cannot continue to have sloppy subscription practices and still get their mail delivered. Improved authentication and better filtering let ISPs pin-point blocks. Instead of having to block by IP or by domain, they can block only some mail from a domain, or only some mail from an IP. There are a number of senders who are sending mail that users do not want mixed with mail that recipients do want. Right now, if there is more mail that recipients want in that mix, then ISPs let the mail through. This will not continue to happen through 2008. Senders will need to send mail users actively want in order to see good delivery.
Less is more. A lot of other email bloggers have talked about this, and I will echo their predictions. Less email is more. Send relevant mail that your customers want. Target, target, target. Good mailers will not send offers to their entire database, instead they will send mail to a select portion of their database.
Feedback loops. Use of feedback loops by recipient domains will continue to grow.
Mobile email. More recipients will be receiving email on mobile devices.
Suggestions for 2008

Read More

DKIM "i=" vs "d=" and Reputation

This really should be part seven of a twelve part series or some such as it deals with an aspect of DKIM that’s really important, but is way down in the details of implementation. (dkim.org is a reasonable place to start for a general overview of DKIM).
There’s an apparently endless thread on the DKIM-SSP spec development mailing list at the moment about the differences between two fields in a DKIM signature that could be used to tie a senders reputation to. Several ESP delivery folks asked me to explain what everyone was talking about, and this post is a first cut at that.
“i=” vs “d=”
There are two possible fields in a DKIM signature that could be used to identify the sender of a message, and so to tie a sender history and reputation record to. They are the so-called “i=” and “d=” field, from the syntax used to include them in the signature.

Read More