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

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

How not to handle unsubscribes

On the heels of my unsubscribe experience last week where an ESP overreacted and unsubscribed addresses that did not belong to me, I encountered another deeply broken unsubscribe process. This one is the opposite, there is no way to unsubscribe from marketing mail at all. Representatives of PayPal have only been able to suggest that if I do not want their mail, that I block PayPal in my email client.
I had a PayPal account years and years ago. They made some extensive privacy policy changes back in 2003 and when I did not actively agree to the new policies, they closed the account. That account closure seemed to take, I heard nothing from PayPal. In early 2008, I made a purchase at a vendor that only accepted credit cards through PayPal. Normally, I do not do business with vendors who only accept payment through PayPal, but there appeared to be a way to make the payment without establishing a PayPal account, so I went ahead and made the purchase.
The receipt from that purchase came from PayPal, and mentioned that I had an existing PayPal account. I figured that because the address was the same as the 2003 account that the boilerplate did not understand ‘closed accounts’. I brushed off the notice and did not worry about it.
On June 23, I received marketing email from PayPal. The mail offered 10% off my first eBay purchase, if I set up an eBay account using the same address on my PayPal account. Yay. Spam. Oh, well, no big deal, there was an unsub link at the bottom of the email. It is PayPal, they are a legitimate company, they will honor an unsubscribe. It will all be fine.
Or. Not.
Clicking on the unsubscribe link in the email takes me to a webpage that tells me I had to login to my account to unsubscribe. But I do not have an account!
They clearly think I have an account linked to the email address they mailed. I decide to see if I can recover the account and then unsubscribe. I put in the email address they sent the marketing email to, the password I probably would have used had I actually set up this account and hit “submit.” PayPal now asks me to set up 3 questions to use to recover my account in case I forget the login in the future. Uh. What? No. I do not want to set up an account, I want them to stop sending me email. I abandon that webpage.
I then attempt to recover the password to the account. Put in the email address that PayPal is sending email to and hit “forgot password”. PayPal, as expected, sends me an email. Click this magic link to recover your account. PayPal then asks me to input the full number of the credit card associated with the account – the credit card number I do not have. What account? What credit card number? Is this from my 2003 subscription that was closed? Is this from the purchase I made in February? I abandon that webpage.
The recover password email helpfully lists a phone number I can call for assistance so I call. In order to be able to talk to someone I have to enter my phone number. And the credit card number associated with my account. I resorted to randomly pounding on “0” and telling the voice recognition software I wanted help. Eventually, it got so confused it transfered me to a real human.
Tragically, the voicemail system was actually more helpful than the real human on the other end. Distilling down hours of sitting on the phone with them, I am told the following:

Read More

New Delivery tools

A couple nifty new delivery tools were published over the weekend.
Mickey published Bounce P.I. where senders can paste in an error message or bounce and it will tell you what filter generated it. If the rejection is unrecognized, it will flag the message internally and it will be researched to see if the filter can be identified.
Steve has a new tool at the DKIMCore site. The key generating tool and the record checking tool have been up for a while. This weekend, though, he published a tool to check the validity the DKIM record published in DNS. Tool output shows if the record is valid, the version and the public key.

Read More