DKIM / Domain Keys Support

What is DomainKeys/DKIM?

DomainKeys/DomainKeys Identified Mail (DKIM) are cryptographic authentication solutions that add signatures to e-mail messages, allowing recipient sites to verify that the message was sent by an authorized sender and not altered in transit.

DomainKeys

DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity. DomainKeys is independent of Simple Mail Transfer Protocol (SMTP) routing aspects. It operates on the RFC 2822 message and not the SMTP envelope defined in RFC 2821. For more information about RFC2822 and RFC2821, see Terminology on page 8.

DomainKeys adds a header named DomainKey-Signature that contains a digital signature of the contents of the mail message. The default parameters for the authentication mechanism are to use SHA-1 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64. For more information about SHA-1 and Base64, see Terminology below.

The receiving SMTP server then uses the name of the domain from which the mail originated, the string _domainkey, and a selector (Selector allows a domain to have more than one public-key in DNS) from the header to perform a DNS lookup. The returned data includes that domain's public key. The receiver can then decrypt the hash value in the header field and, at the same time, recalculate the hash value for the mail body that was received, from the point immediately following the DomainKey-Signature header. If the two values match, this cryptographically proves that the mail did in fact originate at the purported domain, and has not been tampered with in transit.

DomainKeys can specify to a recipient that an e-mail message that purports to be from ‘example.net’ is indeed from ‘example.net’, however it cannot by itself specify whether e-mail from ‘example.net’ is likely to be spam. The mere presence of a signature means nothing about a message's desirability, since spammers can and do sign e-mail message just like anyone else.

DKIM

DKIM builds on previous work in the form of Domain Keys, Identified Internet Mail, Authenticated Sender, Meta-Mail, and so on. DKIM defines a mechanism by which e-mail messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. The responsible organization adds a digital signature to the message, associating it with a domain name of that organization. After an e-mail message has been signed, any agent in the message transit path can select to validate the signature. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

DKIM is upward compatible with existing DomainKeys (DK) DNS records and hence a DKIM module does not automatically require additional DNS administration. DKIM has enhanced the DK DNS key record, to permit the addition of several parameters. DKIM uses a different RFC2822 [RFC2822] header named DKIM-Signature for storing the signature, in order to distinguish it from DomainKeys.

Overview of the Feature

Connect provides the ability to enable or disable the signing of outgoing e-mail messages using DomainKeys/DKIM technology. KANA Connect adds a header named DomainKey-Signature (for DomainKeys) or DKIM-Signature (for DKIM), which contains a digital signature of the contents of the e-mail message.

Connect approach to support DomainKeys/DKIM

The Administrators need to configure various receiver domains using Connect UI. While configuring a receiver domain, Administrators need to specify the private key (from the public or private key pair generated by the domain owner) to be used for signing outgoing e-mail messages. The corresponding public key must be stored in the DNS Server as a TXT record with various defined attributes.

Note: The System Administrators (IT Team) have the option of specifying multiple selectors for a single domain. However, current version of Connect supports only a single selector to be specified for a receiver domain.

Connect determines whether to sign the outgoing e-mail messages based on various configured parameters and then signs the message accordingly. Connect supports signing outgoing messages with DomainKeys using simple or nofws algorithm and DKIM using simple algorithm. For more information about simple and nofws algorithm, see Terminology on page 8. Connect adds DomainKey-Signature header (in case of DomainKeys) or DKIM-Signature (in case of DKIM) in the outgoing e-mail messages.

The receiving SMTP server subsequently queries the DNS server and verifies the digital signature and delivers the e-mail message to customer’s inbox.

The following is an example of a typical DomainKey-Signature header:

 DomainKey-Signature: a=rsa-sha1; s=jun2005.eng; d=example.com;
                [email protected]; c=simple; q=dns;
                b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR
  • a = The algorithm used to generate the signature. The default is "rsa-sha1", an RSA signed SHA1 digest. Signers and verifiers MUST support "rsa-sha1".
  • b = The signature data, encoded as a Base64 string.
  • c = Canonicalization algorithm. Verifiers MUST support "simple" and "nofws". For more information about canonicalization algorithm, see Terminology on page 8.
  • d = The domain name of the signing domain.
  • q = The query method used to retrieve the public key.
  • s = The selector used to form the query for the public key.

As a result, DNS query will be made to:

 jun2005.eng._domainkey.example.com

The following is an example of a typical DKIM-Signature header.

 DKIM-Signature: a=rsa-sha1; c=simple/simple; d=connectify-div.com; s=n1024;
                t=1153444845;
                h=From:Reply-To:To:Subject:Date:Message-ID:X-Mailer:Mime-Version:Content-Type;
                b=qwMjKBRwXbvzwE7l6XShbZ7ZMMrZ0sllxJKL4D8FKUmZX5dOphH

Applicability for Mail Farm

The DomainKeys/DKIM compliance is applicable for Connect instances using either Direct Mail Sending (DMS) or Mail Farm. Administrators can always turn off the DomainKeys/DKIM support at the application level, if the Mail Farm is configured to sign outgoing e-mail messages using DomainKeys/DKIM.

Performance Overhead

There will be an additional overhead involved when DomainKeys/DKIM is enabled to sign outgoing e-mail messages from Connect.

The following can be performed by using the DomainKeys/DKIM feature:

  • Administer receiver domains
  • Configure message signing

Administer receiver domains

Administrators can configure receiver domains with appropriate details required for signing the e-mail messages being sent out. For more details about configuring receiver domains, see Chapter 3, Administering Receiver Domains.

Configure message signing

Administrators can enable or disable signing at system parameter level or conversation level or at the receiver domain level. For more details about configuring message signing, see Chapter 4, Configuring Message Signing.

DomainKeys/DKIM Support - Workflow

Figure 1 shows the workflow of DomainKeys/DKIM feature.



DomainKeys/DKIM Workflow

The following steps describe the workflow of DomainKeys/DKIM feature.

  1. The Conversation Manager picks up a campaign.
  2. The Conversation Manager requests the Mail Sender to send an e-mail message.
  3. The Mail Sender signs the outgoing message based on the configured settings and perform the following steps to sign the outgoing message:
  4. Identifies the sender's domain.: This is extracted from the "From" address of the outgoing e-mail message.
  5. Determines if an e-mail message should be signed.
  6. Selects a private-key (stored in the database).
  7. Performs Canonicalization of the e-mail header and body.
  8. Calculates the signature value.
  9. Adds the DomainKey-Signature (or DKIM-Signature) header to the outgoing e-mail message.
  10. The Mail Sender sends the e-mail message.
  11. The Receiving ISP queries the DNS server for the public key.
  12. The Receiving ISP verifies the digital signature.
  13. The e-mail message is delivered to the customer’s inbox.

Terminology

Base 64

In computing, base64 is a data encoding scheme whereby binary-encoded data is converted to printable ASCII characters. It is defined as a MIME content transfer encoding for use in internet e-mail. The only characters used are the upper- and lower-case Roman alphabet characters (A-Z, a-z), the numerals (0-9), and the "+" and "/" symbols, with the "=" symbol as a special suffix code.

Genrsa

This helps to generate an RSA private key.

Canonicalization

The method by which the headers and content are prepared for presentation to the signing algorithm.

Nofws Algorithm

A canonicalization algorithm (No Folding White Spaces) that tolerates common modifications as white-space replacement and header line re-wrapping.

RFC 2821

This document is a self-contained specification of the basic protocol for the Internet electronic mail transport.

RFC 2822

This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages.

SHA-1

This Secure Hash Algorithm takes a message of less than 264 bits in length and produces a 160-bit message digest designed so that it is computationally very expensive to find a text string that matches a given hash.

Simple Algorithm

A canonicalization algorithm that tolerates almost no modifications.