Structure of the DKIM-Signature header

Products

• Messaging Gateway

Issue/Introduction

You need to analyze the contents of a DKIM-Signature header in order to investigate an issue with Messaging Gateway DKIM signatures
 

Resolution

DKIM Authentication operates by decrypting a cryptographic signature of the email message using a key stored in the DNS and comparing it to a hash of the message headers and body. In order for this to work the sender needs to not only include the signature with the message but details on how to find the correct public key, how it computed the hash and what information needs to be included when checking the signature. All that is wrapped up in the DKIM-Signature message header.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
   c=relaxed/simple;q=dns/txt; [email protected]; t=1255993973;      
   h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:
   MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
   Content-Description:Resent-Date:Resent-From:Resent-Sender:
   Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
   List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:
   List-Archive; bh=+7qxGePcmmrtZAIVQAtkSSGHfQ/ftNuvUTWJ3vXC9Zc=;
   b=dB85+qM+If1KGQmqMLNpqLgNtUaG5dhGjYjQD6/QXtXmViJx8tf9gLEjcHr+musL
   CAvr0Fsn1DA3ZLLlUxpf4ARCRftffOIp55Mj5EtDMm8v1UkcuftmgY9vcvpoPLDz
   yV/7EG/Gnmat6N7qrlC5Ip5sQqSaaaDwenkvOGGuDqs=;

Separators: The DKIM signature header isn’t immediately clear but with a little slicing and dicing will tell us everything we need to know about how to validate the message but it’s important to know where to make the cuts. The header is composed of multiple “tag=value” pairs separated by the semicolon. When taking apart the header, always cut at the semicolon.

v=1

• Version. This is always 1

a=rsa-sha256

• This is the hashing algorithm used to generate the message digest. It will usually be either rsa-sha or rsa-sha256. Other algorithms are possible but not always supported.

d=example.com

• The DNS domain of the signer.

s=selector1

• This defines which value is used in the DNS lookup to determine which public key was used to sign the message. In this case public key would be stored in selector1._domainkey.dkim-test1.com.

c=relaxed/simple

• Message canonicalization identifies the scheme used to prepare the headers and body prior to running it through the hashing algorithm. Some MTAs make small changes to the headers and occasionally the body when relaying messages and message canonicalization can help ensure that this doesn’t negatively impact the DKIM signature. If you’re interested in the gory details please see RFC 4871 or the SBG Admin Guide.
  
   

q=dns/txt

• The q field defines the query method(s) used to retrieve the DKIM public key. It doesn’t have to be present and defaults to “dns/txt”. Currently dns/txt is the only supported method but other methods may be added at a later date.
  
   

[email protected]

• This is the identity of the user or program for which the message has been signed. This can be omitted but if present the domain must match `d` although the username before the `@` may be dropped.
  
   

t=1255993973

• The epoch timestamp marking when the message was signed.
  
   

h=From:…:List-Archive

• The `h` tag contains a colon separated list of the headers included when signing the message headers. Significant modification to these headers while the message is in transit will cause DKIM authentication to fail.

bh=+7qxGePcmmrtZAIVQAtkWSGHfQ/ftNuvUTWJ3vXC9Zc=

• This is the base64 encoded hash of the message body after it has been canonicalized via the method in `c` and then run through the hash function in `a`.

b=dB85+qM+If1KGQmqMLNpqLgNtUaG5dhGjYjQD6/QXtXmViJx8tf9gLEjcHr+musL
CAvr0Fsn1DA3ZLLlUxpf4ARCRftffOIp55Mj5EtDMm8v1UkcuftmgY9vcvpoPLDz
yV/7EG/Gnmat6N7qrlC5Ip5sQqSaaaDwenkvOpGuDqs=;

• Finally, this is the heart of the DKIM signature itself. Everything else up to this point has been meta information on how this value was calculated.