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

DKIM implementation survey

DKIM has been a hot topic of discussion on some of my mailing lists today. One of the open questions is what is holding up adoption of DKIM. I have my own theories, but thought I’d throw out some questions to see how ESPs and ISPs are currently using domain based reputation.
I have set up two surveys one for ESPs and one for ISPs. Responses are anonymous.
I’ll collect responses for a week and share the results.

Read More

Links for 7/8/9

With all the traveling I did last month, I’m still not back to full blogging speed. I have been slowly reading through the backlog of unread posts from my RSS feeds and there was lots of good stuff published.
Three myths about DKIM by John Levine. A very good explanation taking down some of the myths of DKIM. Also on the DKIM front, RFC 5585 DKIM Service Overview was published last month. According to Cisco, DKIM adoption is climbing. More information about DKIM is available at dkim.org and our own dkimcore.org.
The always awesome guys at Mailchimp have embraced twitter as part of their platform. Not only have they  set up their own service for link shortening so that links can be tweeted, but have also incorporated twitter stats into their mail dashboard.
Al has an insightful post on delivery, spam filtering vendors and the differences (or lack thereof) between B2C and B2B marketing. As I tell my customers, there is no switch inside the filtering scheme for “I know this person, they’re OK, let the mail in.”
Terry Zink has started a series about blacklists triggered by the recent SORBS announcement.  His first post, My take on blacklists, part 2, discusses how some people go about building a blocklist from scratch.
Happy 7-8-9 everyone.

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