DKIM Vs. DomainKeys

dkim vs domainkeys

What is DomainKeys

DomainKeys is a domain-level authentication standard that uses public/private key encryption, DNS, and multiple policies to prove the legitimacy and contents of an email message. It verifies the domain used in the “from” or “sender” header. An email message signed with DomainKeys will utilize both a public key record, and a policy record.

Public Key

A public key/private key-pair is created for the sending domain. The private key is stored securely on the mail server, and the public key is stored in the DNS as a TXT record of the domain. Here is an example of a DomainKey text record:

mail._domainkey.example.net. 3600 IN  TXT  "t=y; k=rsa; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg......U4i3CaMu98nwIDAQAB"

A DomainKey text record will contain a number of “tags” or attributes that give more information about the record. In the above example, the following tags were used:

t = The DomainKey is in test mode

k = Defines the key type. RSA is the default.

p = Public key data, encoded as a Base64 string.

DomainKeys Naming Conventions

As DNS text records are already being used for SPF records, to avoid namespace conflicts the DNS namespace “_domainkey” is prepended to the domain. Additionally, a “selector” is then prepended to “_domainkey”. Selectors allow a sending domain to have more than one public key in DNS, and can be any arbitrary name.

The following are examples of DomainKey records:

mail._domainkey.example.com
marketing._domainkey.example.com
default._domainkey.example.com
nyc.staff._domainkey.example.com
sfo.letters._domainkey.example.com

DomainKey Message Configuration and Signing

The actual configuration of DomainKeys varies depending on what respective mail system is being used, and is outside the scope of this document. The signing methodology, however, is consistent across all platforms, per how the RFC standard was written.

Consider the following sample email and accompanying DomainKey signature:

DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;
	s=marketing; d=example.net;
h=Received:Date:From:Reply-to:To:Message-ID:Subject;
b=WHS4P2mFr2k4J+TLrgzjXx3KGQHm...b7EhUUmE0R6Dzvn41e6MrIEM=
Received: from [192.168.1.1]; Fri, 09 Jan 2009 13:52:35 -0800
Date: Fri, 9 Jan 2009 13:52:30 -0800 (PST)
From: Example-Announce 
Reply-to: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Subject: January Announcements

When an email message is signed with DomainKeys, it will include a number of “tags” whose values contain authenticating data for the message being sent. In the example above, the following tags were used:

q = The query method used to retrieve the public key. Currently, the only valid value for this tag is “dns”.

a = The encryption algorithm used to generate the signature. The default value for this tag is “rsa-sha1”.

c = The canonicalization algorithm – or the method by which the headers and content are prepared for presentation to the signing algorithm.

s = The selector used in the public key.

d = The domain name of the signing domain.

h = A colon-separated list of header field names that identify the headers in the email message. The values in this tag MUST contain the complete list of headers in the order presented to the signing algorithm.

b = The signature data or public key, encoded as a Base64 string.

Verifying DomainKeys

There are three primary steps in verifying a DomainKey signed email message:

A receiving mail server extracts the signature information from the headers of the email message, and the public key is fetched from DNS. The public key is matched to private key for validation. All additional tag information is verified.

Once the verification process is complete, the receiving mail server then applies local policies based on the results of the verification, and based on the results can determine whether to deliver the message.

What is DomainKeys Identifed Mail?

What is DKIM? DomainKeys Identified Mail (DKIM) is the successor to Yahoo DomainKeys, which uses a digital signature to verify that the email was sent and authorized by the owner of the domain. Being very similar in functionality to DomainKeys, DKIM has additionally adopted aspects from Cisco’s Identified Internet Mail standard (IIM), and the result has been an enhanced standard that provides more flexibility and security than its predecessor. Some of the differences between DomainKeys and DKIM include:

  • Multiple signature algorithms (as opposed to just one available with DomainKeys)
  • More options with regard to canonicalization, that validates both header and body
  • The ability to delegate signing to third parties
  • The ability for DKIM to self-sign the DKIM-Signature header field – to protect against its being modified
  • The ability for wildcard option on some parameters
  • The ability to support signature timeouts in DNS

DKIM Message Configuration and Signing

DKIM message signing is very similar to DomainKey signatures. There are a number of extra tags available that authenticate different aspects of an email message.

Consider the following sample email and accompanying DKIM signature:

DKIM-Signature:v=1; a=rsa-sha256; d=example.net; s=v1; c=simple/simple;
q=dns/txt; [email protected]; t=1231537955;
h=Received:Date:From:Reply-to:To:Message-ID:Subject;
bh=YXMEQF450z/x8OwmM2cXB0sn8pQ=;
b=V4eYEm7zx1aNgbBaTgljjJ6lvU7xCEDeg2lE5KXMRZW...HSkBHlKnbICHCu3CTxqe8ys=;
Received: from [192.168.1.1]; Fri, 09 Jan 2009 13:52:35 -0800
Date: Fri, 9 Jan 2009 13:52:30 -0800 (PST)
From: Example-Announce 
Reply-to: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Subject: January Announcements

Note that there are tags that are seen in a DomainKey signature, as well as some additional tags only used by DKIM. Following is a description of the tags used in the above example:

v = The version of the DKIM specification being used to sign the message.

a = The algorithm used to generate the signature.

d = The domain of the signing entity.

s = The selector used in the public key.

c = The canonicalization algorithm – or the method by which the headers and content are prepared for presentation to the signing algorithm.

q = The query method(s) used to retrieve the public key.

i = The identity of the user or agent (e.g., a third party) on behalf of which this message is signed.

t = Signature timestamp. The format is UNIX time format.

h = A colon-separated list of header field names that identify the headers in the email message. The values in this tag MUST contain the complete list of headers in the order presented to the signing algorithm.

bh = The hash of the canonicalized body part of the message.

b = The signature data or public key, encoded as a Base64 string.

Verifying DomainKeys

Verification of DKIM signed email messages is done in virtually the same fashion as with messages signed with DomainKeys.

Try Our Free DKIM Generator

Email Authentication

SPF is just one small part of the greater email authentication topic.  To learn more about the bigger email authentication picture, including DKIM and DMARC, check out the SocktetLabs Email Authentication Hub!