A quick marketers guide to DKIM

J.D. Falk posted a brief but comprehensive guide to the different DKIM flags: what they mean and how they may affect delivery. (The original link seems to be dead so I reproduced the blog post for reference It’s just that good. A DKIM Primer Resurrected

DKIM only answers two questions:

  • Does the message have a valid signature?
  • If it does, what domain signed it?

The signing domain, identified by the d= tag in the DKIM signature header, is the only part of the DKIM signature where the choices you make now will directly affect the continued deliverability of your messages. This is because d= is how you tell the receiving system who you are.

J.D. goes on to describe the different flags and how they may affect delivery of a particular signed message. It’s a good review of the flags and what they mean.

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

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

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.

Read More