DomainKeys Identified Mail DKIM

DomainKeys Identified Mail (DKIM) allows senders to associate a domain name with an email message, thus vouching for its authenticity.

DKIM is a form of email authentication that allows an organization to claim responsibility for a message in a way that can be validated by the recipient. DKIM uses “public key cryptography” to verify that an email message was sent from an authorized mail server, in order to detect forgery and to prevent delivery of harmful email like spam.


How DKIM Works

Simply put, DKIM works by adding a digital signature to the headers of an email message. This signature can then be validated against a public cryptographic key that is located in the organization’s DNS record.

The domain owner publishes a cryptographic key. This is specifically formatted as a TXT record in the domain’s overall DNS record.

After a message is sent by an outbound mail server, the server generates and attaches the unique DKIM signature to the header of the message.

The DKIM key is then used by inbound mail servers to detect and decrypt the message’s signature and compare it against a fresh version. If the values match, the message can be proved authentic, and unaltered in transit, and therefore, not forged or altered.

MultipleDKIM Records

There are two types of DKIM DNS records:

  • The policy record contains information about the DKIM signing policy and the email address of the postmaster. There should only ever be one of these.
  • The DKIM DNS record with the long string of gibberish is the public signing key. A domain can have many of these as it has servers with private keys that sign emails. Each of these should have a selector that uniquely identifies it. If there is just one, it may have no selector at all, just "_domainkey". Additional ones would use selectors to keep them all separated, for example "list._domainkey" and "bananas._domainkey".

Selectors are how receiving servers know which public key to use for an email and which corresponding private key was used to sign the email.

How Can I Read the DKIM Header?

Here is an example DKIM signature (recorded as an RFC2822 header field) for the signed message:

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

Let’s take this piece by piece to see what it means. Each “tag” is associated with a value.

  • b = the actual digital signature of the contents (headers and body) of the mail message
  • bh = the body hash
  • d = the signing domain
  • s = the selector
  • v = the version
  • a = the signing algorithm
  • c = the canonicalization algorithm(s) for header and body
  • q = the default query method
  • l = the length of the canonicalized part of the body that has been signed
  • t = the signature timestamp
  • x = the expire time
  • h = the list of signed header fields, repeated for fields that occur multiple times

We can see from this email that:

  • The digital signature is dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR.
    This signature is matched with the one stored at the sender’s domain.
  • The body hash is not listed.
  • The signing domain is example.com.
    This is the domain that sent (and signed) the message.
  • The selector is jun2005.eng.
  • The version is not listed.
  • The signing algorithm is rsa-sha1.
    This is the algorith used to generate the signature.
  • The canonicalization algorithm(s) for header and body are relaxed/simple.
  • The default query method is DNS.
    This is the method used to look up the key on the signing domain.
  • The length of the canonicalized part of the body that has been signed is not listed.
    The signing domain can generate a key based on the entire body or only some portion of it. That portion would be listed here.
  • The signature timestamp is 1117574938.
    This is when it was signed.
  • The expire time is 1118006938.
    Because an already signed email can be reused to “fake” the signature, signatures are set to expire.
  • The list of signed header fields includes from:to:subject:date.
    This is the list of fields that have been “signed” to verify that they have not been modified.