Domain Key Identified Mail – DKIM

4.3 Domain Key Identified Mail – DKIM [RFC 6376]

DKIM is a mechanism for digitally signing a message. Unlike SPF which is specifically designed to identify non-legitimate Email, DKIM is not designed as a counter-fraudulent Email/spam control, but instead to secure legitimate messages by detecting tampering or corruption of the message contents.

Although message integrity is outside the scope of this paper, DKIM can and is used to infer whether a signed message has been sent by the legitimate domain owner, as only the legitimate domain owner will be able to sign the message with the genuine signing key. Hence while primarily aimed at message integrity, DKIM does provide another mechanism by which recipient mail servers can determine whether a message was sent by the legitimate domain owner.

DKIM merged and enhanced DomainKeys, from Yahoo! and Identified Internet Mail, from Cisco and was introduced in 2004. Like SPF, DKIM also employs a DNS text (TXT) record mechanism, however, unlike SPF, it requires additional work by the mail sender who must organise a message signing infrastructure. This can represent a significant investment if an organisation sends large volumes of Email via a wide range of service providers and/or its own servers. The signing of Email demands computing power and so suitable additional processing capacity must be available within the organisation’s Email infrastructure.

DKIM is based on asymmetric encryption using a private/public key pair. The private key is used by the legitimate mail sender to digitally sign outgoing mail by adding an encrypted hash value of the message to the SMTP mail header. The receiver then obtains the legitimate sender’s public key from a DNS text (TXT) record and so by re-computing the hash value, is able to determine whether the included digital signature was created by the legitimate sender.

Like SPF, DKIM is reliant on the receiving party implementing DKIM checks and this too requires the receiving party to provide sufficient computing power and infrastructure to undertake the digital signing checks which are comparatively computing-intensive.

The other key aspect of DKIM is that mail is always accepted regardless of whether a message is correctly signed, as the specification does not specify an action the receiver should perform should a message fail the signing check. This illustrates DKIM’s primary focus on message integrity, not fraudulent Email detection.

Instead DKIM is offered as “an enabling technology” to assist the receiver sort legitimate from fraudulent Email. Hence the primary value of DKIM is to assist in the delivery of legitimate Email by large ISPs such as Yahoo!, Hotmail or Google, all of whom support DKIM, rather than to have fraudulent Email rejected. The emphasis is therefore on the beneficial consequence to the legitimate sender of passing a DKIM check rather than the expectation of the rejection of fraudulent Email failing a DKIM check. To address this issue DKIM is extended by Author Domain Signing Practices (ADSP) which is described next.

Implementing DKIM therefore includes two aspects:

  1. Providing infrastructure to perform the digital signing of all Email sent
  2. The publishing of suitable DKIM records in the domain’s DNS zone file


DKIM employs two or more DNS text (TXT) records, the first to define the DKIM policy in force and the second (or others) to provide the public key(s) used for signing. The reason for potentially more than one public key is to enable an organisation to use multiple signing keys. Example records would be:


_domainkey.example.com. IN TXT "o=~"
key_id._domainkey.example.com. IN TXT "k=rsa; p=[public_key_value]"
Figure 9 – Example DKIM records

The first record defines the DKIM policy in use:

  • "o=~" indicates that only some Email from the domain will be digitally signed
  • "o=-" would indicate that all legitimate Email should be signed


You may recognise the reuse of the SPF ‘~’ (soft) and ‘-‘ (hard) qualifiers.

The second record uses a ‘selector’ name in front of the _domainkey name. The selector is in effect a key name or identifier, shown here as key_id. This allows a domain to use multiple keys which may be useful if, say, a third party Email service is being used to distribute mail for the domain or if the organisation sends Email from a number of different sets of infrastructure. Each infrastructure can then use a separate signing key, meaning an organisation doesn’t need to give an external third party access to a key it uses itself. Likewise, an organisation may choose to rotate keys periodically, thereby allowing both the old and new key to be published simultaneously during the cut-over period.

Any signed Email carries the selector name used for the message signing in its message header, thereby permitting a DNS lookup and signature check to be completed by the recipient mail server.

The "k=rsa" declares that the public key is based on the RSA public-key cryptosystem (the only algorithm currently supported and can therefore be omitted) and the "p=[...]" is the public key value.

A DKIM signature is added as an RFC2822 header field in the signed message , for example:


DKIM-Signature v=1; a=rsa-sha1; q=dns/txt;
d=example.com; i=user@eng.example.com;
s=jun2005.eng; c=relaxed/simple;
t=1117574938; x=1118006938;
h=from:to:subject:date;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Figure 10 – Example DKIM signature included in a signed message header

To explain this header:

  • v: The DKIM version in use (mandatory)
  • a: The signing algorithm used
  • q: A colon-separated list of query methods that should be used to retrieve the public key. Currently, the only valid value is “dns/txt
  • d: The signing domain
  • i: The identity of the user (or agent) on behalf of whom this message is signed
  • s: The selector or key ID used for the signing, e.g. jun2005.eng shown would translate into a DNS record in the name of jun2005.eng._domainkey.example.com
  • c: The canonicalization algorithm(s) used for header and body
  • t: The signature timestamp
  • x: The message expire timestamp
  • h: The list of signed header fields, repeated for fields that occur multiple times
  • b: The actual message signature value


For full details of the possible header fields and their meaning, refer to RFC4871.

Like SPF, DKIM can also suffer ‘collateral damage’ with genuine mail failing a DKIM signature check. This is typically caused by some mail gateway adding something to a message, for instance an anti-virus scanning or privacy statement. Messages distributed via Email distribution lists can also suffer similar corruption due to inserted text, resulting in a signature failure.

Continue reading ‘Author Domain Signing Practices – ADSP’ »