DomainKeys Identified Mail (DKIM) is a way to use digital signatures to bind an email message to the domain that it originated from. A work in progress by the IETF, DKIM has yet to be widely implemented. However, VARs and consultants can utilize DKIM in an overall email solution to take some load off a customer's local email protection. If a domain certifies that a piece of mail comes from itself, it's a simple matter to use this technique to validate that assertion. DKIM can also be useful in protecting against spoofing attacks.
 |
| Email Security Project Guide |
| Find more tips and strategies for securing your customer's email systems in our Email Security Project Guide, designed specifically for channel professionals. |
|
|
|
|
The concept of DKIM is simple. A domain attaches a signature to an email, and a client queries the domain to get its public key, which is stored in the Domain Name Server. The signature travels with the message, and the signing key is in the network. That public key is then used to verify the system acting as the sender of the message, not the contents of the message. DKIM can also allow "whitelisting" on the client side, which establishes trust between a domain and a user.
In order to use DKIM, signers need to add code to the appropriate program to perform the signing. They also need to modify their DNS administrative tools to permit creation of DKIM key records. VARs and consultants can ensure their customers are capable of doing this kind of DNS lookup on their Internet gateway, but the DKIM implementation must also be done by the domain sending the email.
Validators need to add code to the appropriate agents and then feed the results into the portion of their systems needing it, such as filtering engines.
The mere existence of a valid signature does not imply that the mail is acceptable, such as for delivery. Acceptability requires an assessment phase. Hence the result of signature validation must be fed into a vetting mechanism that is part of the validator's filter.
DKIM is based on domain names, rather than complete email addresses, which are used by OpenPGP and S/MIME standards. Signing is therefore is controlled by the administrator of the domain name, not by individual email users. If the domain is internal to the enterprise, then the consultant may implement DKIM for both internal and external use. However, domains external to the enterprise must implement DKIM themselves for it to be useful.
DKIM uses DNS-based self-certified keys, thereby eliminating the need for a public key infrastructure. Moreover, DKIM does not modify the message body like S/MIME and OpenPGP. Instead, it inserts information into header fields, which are usually not shown to the recipient. As a result, DKIMs can be entirely invisible to recipients, and consultants need only to train the IT staff directly involved with the technology.
DKIM can be an effective deterrent to phishing and spoofing. It requires that a domain sign its DNS records for others to use in verification of mail sent by it. Any size organization may benefit from this kind of validation because it provides a way for mail recipients to check the validity of that mail. The structure of DKIM means that the checking may be done at the mail server, independently of the user's mail client. There is little maintenance involved since it's up to the sender to insert DKIM information in the message header and have their DNS record contain their public key.
About the author
Larry Loeb has been online since the world revolved around {!decvax}. He's been in many of last century's dead tree magazines about computers, having been a Consulting Editor to the late, lamented BYTE magazine, among other things. You can reach him at larryloeb@larryloeb.com.
