DomainKeys Identified Mail (DKIM) [RFC5585] is intended to provide an associa- tion between an entity and a domain name that can be used to help determine the party responsible for originating a message, especially in the e-mail context.
ptg999 It provides a method to help authenticate the signer of a message, which is not
necessarily the sender, and this can be used in helping to fight spam at the e-mail distribution level (i.e., between mail agents). This is accomplished by adding a DKIM-Signature field to the basic Internet message format [RFC5322]. This field contains a digital signature of the header and body of the message. DKIM replaces an earlier standard called DomainKeys, which uses the DomainKey-Signature field.
18.11.1 DKIM Signatures
To produce a digital signature for a message, a Signing Domain Identifier (SDID) uses RSA/SHA-1 or RSA/SHA-256 and an associated private key. SDIDs are domain names from the DNS and are used to retrieve public keys stored as TXT RRs. A DKIM signature is encoded as a message header field using Base64 (such as PEM) that signs an explicitly listed set of message fields and the message body.
When receiving an e-mail, for example, a mail transfer agent uses the SDID to perform a DNS query to find the corresponding public key, which it then uses to verify the signature. This avoids requiring a PKI. The owning domain name is constructed from the domain itself along with the selector (public key selector). For example, the public key for the selector key35 in domain example.com would be a TXT RR owned by key35._domainkey.example.com.
The DKIM-Signature field [RFC6376] is added to a message header and may contain several subfields (see [DKPARAMS] for the complete list). The operation of DKIM is conceptually similar to the DNS Sender Policy Framework (SPF; see Chapter 11) but is stronger because of the cryptographic digital signature. DKIM and SPF can be used together.
DKIM-enabled domains may elect to participate in Author Domain Signing Practices (ADSP) [RFC5617]. ADSP involves the creation of a machine-readable signing practices statement for a domain. Such records are placed in the DNS using TXT RRs with owner name equal to _adsp._domainkey.domain.. At present ADSP records are simple and indicate only how the authoring domain uses DKIM signatures. The values may be unknown, all, or discardable. These are really hints as to what a receiving agent might do with a received message. The value unknown indicates no particular statement, all indicates that the author signs all messages but unsigned ones may still be worthwhile, and discardable indi- cates that unsigned messages should be considered subject to discarding. dis- cardable is the most stringent level.
18.11.2 Example
To get an idea of how a DKIM signature appears in an e-mail, we can simply extract the DKIM-Signature field from an e-mail message generated from a large e-mail provider such as Google’s Gmail:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
ptg999 Section 18.11 DomainKeys Identified Mail (DKIM) 917
h=domainkey-signature:mime-version:received:
sender:received:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=PU2XIErWsXvhvt1W96ntPWZ2VImjVZ3vBY2T/A+wA3A=;
b=WneQe6kpeu/BfMfa2RSlAl1TvYKfIKmoQRXNc IQJDIVoE38+fGDaj0uhNm8vXp/8kJ I8HqtkV4/P6/QVPMN+/5bS5dsnlhz0S/YoP bZx0Lt2bD67G4HPsvm6eLsaIC9rQECUSL MdaTBK3BgFhYo3nenq3+8GxTe9I+zBcqWAVPU=
This indicates a version 1 signature and digest algorithm of SHA-256 signed using RSA. The header and body canonicalization algorithms are both “relaxed,” as shown by the c= field. Canonicalization algorithms are used to rewrite messages in a consistent form. The current options are “simple” (the default), which does not alter the text, and “relaxed,” which can rewrite the input in common ways such as altering whitespace and wrapping long header lines. The selector (s=) is called gamma and the domain (d=) is gmail.com. We shall use these later to retrieve the appropriate public key. The header fields used in computing the signature (indicated by h=) include domainkey-signature (predecessor to DKIM), ver- sion of MIME, received, sender date, x-google-sender-auth, message-id, subject, from, and content-type. The bh= subfield indicates the hash value on the message body expressed in Base64. The b= value contains the RSA signa- ture on the hash of the headers listed in the h= subfield.
To retrieve the public key to validate the signature, we can form the following query:
Linux% dig gamma._domainkey.gmail.com. txt +nostats +noquestion
; <<>> DiG 9.7.2-P3 <<>> gamma._domainkey.gmail.com. txt +nostats +noquestion
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17372
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; ANSWER SECTION:
gamma._domainkey.gmail.com. 296 IN TXT "k=rsa\; t=y\; p=MIGfMA0GCS qGSIb3DQEBAQUAA4GNADCBiQKBgQDIhyR3oItOy22ZOaBrIVe9m/iME3RqOJeasANSpg2YTHTYV +Xtp4xwf5gTjCmHQEMOs0qYu0FYiNQPQogJ2t0Mfx9zNu06rfRBDjiIU9tpx2T+NGlWZ8qhbiLo 5By8apJavLyqTLavyPSrvsx0B3YzC63T4Age2CDqZYA+OwSMWQIDAQAB"
This result indicates that the key is an RSA public key. The t=y entry denotes that the domain is testing DKIM, meaning that the results of any DKIM validation should not ultimately affect the message delivery process. To see an example of an ADSP, we can execute the following command:
Linux% host –t txt _adsp._domainkey.paypal.com.
_adsp._domainkey.paypal.com descriptive text "dkim=discardable"
ptg999 Here we can see that Paypal has elected to use the most stringent DKIM sign-
ing policy, suggesting that messages failing DKIM validation should be subject to being discarded. The use of ADSP statements at present is fairly rare because of the wide variety of e-mail systems and the ways that various mail agents rewrite messages.