DKIM Records
Updated over a week ago

What is DKIM?

DomainKeys Identified Mail (DKIM) is a method for cryptographically authenticating a message and validating the domain it originated from. DKIM will attach a domain name identifier to a message. Verification is carried out by using the public key's record that will be published within their DNS zone file as a TXT record. This key provides a guarantee that the email has not been modified since the signature was assigned to the message. DKIM keys are not visible to end-users and attached and verified by backend processes. DKIM allows the author to designate which emails it considers legitimate. On its own, it does not directly prevent or disclose offending behavior. 

How does it work?

DKIM can be separated into two main parts Signing and Verifying. DKIM specification allows the author to choose the header field they sign but the From: field must always be signed. 


This can be done by either a direct handler of the email ( intermediary along the path, author, form, etc.. ) or a 3rd party that provides assistance to direct handler.  Signing involves inserting one or multiple DKIM-Signature header fields, acting on the author's behalf.


Verifying modules act on behalf of the receiving organisation, it is possible to verify at each hop between sending and receiving server. The verifier will query the TXT record using the following format:

     or using the example below

The selector is just a straightforward method to allow signers to add and remove keys as they wish. 


The data that is returned from this query will also be a list of tag-value pairs. It will include the domain's public key as well as the other keys, token, or flags that are specified within the TXT record. The receiver will then use this information to decrypt the hash value in the header field while also recalculating the           hash value for the email (header and body). If the two match, this proves that the mail was signed by the specified domain and was not tampered with in transit. 

A failure does not force the rejection of the message, instead the reason why the message was not authenticated should be available to both up and downstream processes. This can be accomplished by utilizing feedback loops or adding Authentication-Results header field to the message. DKIM, at its core, is a method for labeling a message, it does not filter or identify spam. If spammers are forced to show a true source domain, this allows other filtering techniques to work more efficiently and effectively. 

DKIM can be used to deter phishing as well. Mail can be signed using DKIM signatures to show that said mail is genuine. The receiving servers can then take the absence of a signature to be an indication that the mail is likely forged or spoofed. Currently, utilizing DMARC records will allow the author to give a suggestion as to what happens with mail that fails DKIM  verification. Ultimately, the action to take for DKIM failures lies with the receiving server.

Ideally, and this is a major point, the DKIM key length would be AT LEAST 1024 bit. Google, Yahoo, Live, etc currently are failing or will be failing in the near future any DKIM key less than 1024 bit length. 

Parts of a DKIM record:

DKIM-Signature: v=1; a=rsa-sha256;; s=brisbane;

     c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;





The DKIM-Signature header field is a list of tag=value parts. Listed below are the tags and their use/meaning:

  b  = The actual digital signature of the contents (header and body) 

  bh = Body Hash

  d  = Signing Domain

  s  = Selector

  v  = Version

  a  = Signing algorithm

  c  = Canonicalization algorithm for header and body

  q  = The default query method

  l  = Length of the canonicalized part of the body that has been signed

  t  = Timestamp

  x  = Expiry time

  h  = List of signed header fields, this is repeated for fields that occur multiple times 

Information for this post was gathered from the following sites:

Did this answer your question?