Implementing DKIM and how you can get more email delivered and lower the likelihood that a message will be categorized as spam.
In a previous column, I discussed best practices for implementing DomainKeys Identified Mail (DKIM) as a receiver of email. While one of the key challenges for a receiver of email today is around whether or not they can trust that email they receive is not a scam (i.e. phishing), it’s also important to understand what a sender should be doing for sender authentication. In this latest column, I’ve focused on Sender authentication, a technology for a receiver to know that an email comes from where it claims to come from that requires both the receiver and the sender to participate in sender authentication.
When the Internet protocols were created, the Internet (the ARPANet at the time) was a collegial place of research institutions. There were few nodes on the network and there was no commercial exploitation of the Internet. Little thought was given to building into the network protocols that included a method for verifying identity. When the Internet opened to the masses and commercial operations (the creation of .com) spammers and fraudsters exploited the lack of ability to verify identity. The sender addresses of email are forged, in an effort to get unwanted and dangerous email content delivered. Victims of spam and fraud no longer trust the email they receive. Sender authentication is a set of technologies to bring trust back to email. DKIM is the only Internet standard sender authentication technology. The other common methods—SPF and SenderID—are experimental.
How DKIM Works
DKIM is a cryptographically based sender authentication method that uses public key cryptography. The beauty of DKIM is that it does not suffer from the key distribution problems of previous public key cryptography solutions. An existing universal distributed database, DNS, the system that permits IP addresses to be matched to machine names and makes the Internet work, is leveraged to distribute the public keys needed for DKIM. The way DKIM works is that a message, as it is sent, is digitally signed with a cryptographic hash. The receiver of a message verifies the signature using a public key in DNS. The results of the verification as then stored in an Authentication-results: header in the message.
What Verifiers Do with DKIM Results
The result may be used by receivers as part of anti-spam filtering and the results may be represented in the mail user agent, such as Yahoo! Mail, the end-user uses to view her email. As verification is deployed at major Internet service providers today, DKIM is used to:
1. Set class of service
2. Influence the likelihood of a message being classified as spam
3. Inform users on the trust of an email in the mail user agent
Class of service relates to the number of allowable messages or connections the ISP will accept from a given source. Thus DKIM can help you get more email delivered. Success in the DKIM verification will lower the likelihood that a message will be categorized as spam, as long as the sender is a good network citizen. Every major ISP uses reputation lists for senders. Email messages from senders with good reputation that is signed will be more likely to be delivered to the inbox rather than the spam folder. As a best practice, the receivers will expose the results of DKIM verification to the end-user. So, if a firm wants to maximize delivery of email messages to their customers, it would behoove the sending firm to DKIM sign the email.
What does a company do when they contract out the sending of email to a third-party? The good news is that DKIM permits the delegation of DNS name space and keys to third-parties. The best option is to make sure, when selecting a bulk email vendor, that the bulk email vendor supports DKIM signing and delegate a set of keys to them. You want to delegate a new set of keys rather than sharing the existing keys used by the company, because you want to be able to revoke the keys if you switch vendors.
Summary of Best Practices for DKIM
The following is a list of best practices for senders of email (DKIM signers).
1. Sign all your mail - The raison d’être of sender authentication is to bring trust back to email. If all mail is not signed, receivers have less confidence that unsigned mail is legitimate mail from the sender’s domain.
2. Delegate keys to third-parties - When keys are delegated to third-parties to sign with, they may be revoked if abuse is detected, or the vendor is no longer used.
3. Use the test flag when first implementing DKIM - There is provision in the DKIM standard for a test flag to be set, so that a receiver who is verifying is notified that they should not assume a failure is a fraudulent email. This will prevent legitimate email from being blocked while the kinks in the DKIM deployment are worked out.
4. Do not expect user-level signing to work - Part of the DKIM specification allows it to be extended from the domain to the per-user level on DKIM signatures. The problem is that it is unimplemented at receivers and in most instances will result in DKIM verification failures.
If the above best practices are implemented along with compliance with CAN-SPAM and generally being a good network citizen, such as complying with message and connection rates set by the ISPs’ postmasters, deliverability of email will be increased.