eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Editor’s Note: In Part 1 of her three-part series on e-mail authentication, Knowledge Center contributor Ellen Siegel shared a comprehensive, high-level overview of e-mail authentication. In Part 2, Ellen delved into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. Here, in Part 3, Ellen delves into the functionality and technical details of Domain Keys Identified Mail (DKIM).
Domain Keys Identified Mail (DKIM) is the standards track protocol for cryptographic e-mail authentication and is imperative for new implementations. It supersedes DomainKeys, so this article will focus there. The only reason to implement DomainKeys for outbound mail is if you’re sending mail to one of the few domains that still validate Domain Keys and have not upgraded to DKIM (currently Yahoo is the main receiver in this category).
Unlike Sender ID and Sender Policy Framework (SPF), implementing DKIM and DomainKeys does require changes to sender mail processing. The good news is that very few people actually do their own implementation. The more common approach is to either outsource your e-mail, or to identify an open-source or commercial implementation that is compatible with the mail server you use and integrate it into your deployment.
Basis steps for setting up DKIM or DomainKeys
The basic steps for setting up DKIM or DomainKeys for outbound mail are:
Step No. 1: Identify and install the signing module on each mail server that will be signing outbound mail for your domain(s)
Step No. 2: Generate one or more public/private key pair(s) to enable the signing
Step No. 3: Construct and publish each public key record(s) in the relevant Domain Name Service (DNS) entry
Step No. 4: Install the appropriate private key on each signing mail server
Step No. 5: Test your deployment
The list of products and services that support DKIM is maintained on the DKIM.org Web site. The DKIM.org Web site also provides a DKIM FAQ and a list of consulting services. Many of the DKIM implementations also support DomainKeys or you can also check out the SourceForge Project page. Many implementations allow independent installation of outbound (sending) and inbound (validating) components, so make sure you choose the configuration that is right for your deployment.
Different packages provide different interfaces, so once you’ve set up and configured your new packages, you’ll need to follow their specific instructions for the steps enumerated earlier. Some will provide support for all of the steps. Others may require you to perform specific steps such as publishing public keys via external processes.
Sender Configuration Options
Sender configuration options
There are a number of variables that must be considered when setting up DKIM for outbound e-mail. Most of these will be discussed in the documentation for your selected implementation, but we’ll highlight a few here as well. There are four main choices to make:
1. What encryption algorithm to use – You should use the rsa-256 encryption algorithm recommended by the DKIM specification.
2. What size encryption key to use – Large keys are more secure, but they may also negatively impact performance. The specification recommends a key of at least 1,024 bits.
3. Which parts of your e-mail to sign – In general, you should follow the recommendation in the specification of which headers to include in the signature. In general, you want to include headers that you want to protect (for example, the To, Subject, From, Sender and Date headers) and NOT sign headers that are likely to change during normal processing.
4. The name under which each key record is stored – Key record names include a configurable prefix called a selector that must be unique for each key. This enables domains to use different keys for distinct categories of e-mail (for example, marketing e-mail and corporate e-mail might have different keys), and it also enables periodic replacement of keys to minimize the risk of compromised security.
A DKIM signature provides all of the above configuration information, as well as the signature itself, to the receiver. Here’s an example:
A corresponding key record might look like this:
Using an E-mail Service Provider
Using an e-mail service provider
If you want to send authenticated e-mail but don’t want to set it up on your own, almost all reputable e-mail service providers (ESPs) already support authentication. Any of them should be able to either publish your authentication records for you or give you guidance on how to publish them. If all of your e-mail goes through the ESP, then you’re done! If you maintain corporate e-mail servers separate from those of your ESP, though, you’ll still need to set up authentication for your own domain(s).
Using an ISP account
If you use an e-mail address from your ISP, your e-mail address will look similar to [email protected], for example, and you won’t have any access to the DNS for your e-mail domain.
The good news is that many of the major ISPs are authenticating their outgoing mail. The bad news is that, because you are sharing the authentication identity with all the other customers of your ISP, the authentication won’t do you much good. There are likely many “legitimate” customers of your ISP who are using their accounts to send out abusive e-mail.
If you want to be able to build up a positive sender reputation that really belongs to you, your own authentication domain-either managed on your own or by using an ESP or ISP-is really your only viable option.
Testing your Authentication Deployment
Testing your authentication deployment
Now that you’ve got your sender authentication all set up, you will need to test it to make sure it’s doing what you intend. A great way to do this is to use a testing tool called a reflector. To use a reflector, you send your authenticated message to the specified reflector e-mail address, and it will “reflect” back to you a message that tells you the state of your authentication (usually Pass, Fail or Neutral if there is no authentication information present).
There are a number of reflectors out there. You can see a list of some that support DKIM here. Sendmail’s reflector is particularly useful because it returns results for all four types of authentication in the same reflector response message with just the basic status. The Port 25 reflector gives results for all four authentication types, and also includes details on the DNS records it finds in its verification. But it reflects to the Return-Path address so you may not be able to access the results unless you have help from your e-mail administrators.
Remember, it’s all about reputation
It’s important to remember that a valid authentication does not necessarily mean that the sender is legitimate or that the e-mail is permission based; many spammers use e-mail authentication too. Similar to the way that your driving record influences your insurance rates, most systems that do inbound authentication checking incorporate some kind of reputation checking mechanism before deciding how to process the message.
The authenticated domain’s past sending behavior (good, neutral or poor reputation) will be what really determines how an authenticated message is treated. Authentication adds the assurance that the collected reputation really belongs to the authenticated domain, so that reputation can neither be hijacked nor corrupted by a spammer that forges or spoofs the domain name.
Editor’s Note: In Part 1 of her three-part series on e-mail authentication, Knowledge Center contributor Ellen Siegel shared a comprehensive, high-level overview of e-mail authentication. In Part 2, Ellen delved into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. Here, in Part 3, Ellen delved into the functionality and technical details of Domain Keys Identified Mail (DKIM).
Ellen is a board member and technical committee co-chair for the E-mail Sender and Provider Coalition (ESPC) and an active member of the Messaging Anti-Abuse Working Group (MAAWG). She can be reached at [email protected].