Network Working Group E. Allman
Request for Comments: 4871 Sendmail, Inc.
Obsoletes: 4870 J. Callas
Category: Standards Track PGP Corporation
M. DelanyM. Libbey
J. FentonM. Thomas
Cisco Systems, Inc.
May 2007 DomainKeys Identified Mail (DKIM) Signatures
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The IETF Trust (2007).
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs). The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Protection of email identity may assist in the
global control of "spam" and "phishing".
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key,
and thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
The approach taken by DKIM differs from previous approaches to
message signing (e.g., Secure/Multipurpose Internet Mail Extensions
(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:
o the message signature is written as a message header field so that
neither human recipients nor existing MUA (Mail User Agent)
software is confused by signature-related content appearing in the
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities;
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation;
o signature verification failure does not force rejection of the
o no attempt is made to include encryption as part of the mechanism;
o message archiving is not a design goal.
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
o can be deployed incrementally;
o allows delegation of signing to third parties.
1.1. Signing Identity
DKIM separates the question of the identity of the signer of the
message from the purported author of the message. In particular, a
signature includes the identity of the signer. Verifiers can use the
signing information to decide how they want to process the message.
The signing identity is included as part of the signature header
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field because of the broad methods of interpretation by
recipient mail systems, including MUAs.
DKIM is designed to support the extreme scalability requirements that
characterize the email identification problem. There are currently
over 70 million domains and a much larger number of individual
addresses. DKIM seeks to preserve the positive aspects of the
current email infrastructure, such as the ability for anyone to
communicate with anyone else without introduction.
1.3. Simple Key Management
DKIM differs from traditional hierarchical public-key systems in that
no Certificate Authority infrastructure is required; the verifier
requests the public key from a repository in the domain of the
claimed signer directly rather than from a third party.
The DNS is proposed as the initial mechanism for the public keys.
Thus, DKIM currently depends on DNS administration and the security
of the DNS system. DKIM is designed to be extensible to other key
fetching services as they become available.
2. Terminology and Definitions
This section defines terms used in the rest of the document. Syntax
descriptions use the form described in Augmented BNF for Syntax
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Elements in the mail system that sign messages on behalf of a domain
are referred to as signers. These may be MUAs (Mail User Agents),
MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other
agents such as mailing list exploders. In general, any signer will
be involved in the injection of a message into the message system in
some way. The key issue is that a message must be signed before it
leaves the administrative domain of the signer.
Elements in the mail system that verify signatures are referred to as
verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.
In most cases it is expected that verifiers will be close to an end
user (reader) of the message or some consuming agent such as a
mailing list exploder.
There are three forms of whitespace:
o WSP represents simple whitespace, i.e., a space or a tab character
(formal definition in [RFC4234]).
o LWSP is linear whitespace, defined as WSP plus CRLF (formal
definition in [RFC4234]).
o FWS is folding whitespace. It allows multiple lines separated by
CRLF followed by at least one whitespace, to be joined.
The formal ABNF for these are (WSP and LWSP are given for information
WSP = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS = [*WSP CRLF] 1*WSP
The definition of FWS is identical to that in [RFC2822] except for
the exclusion of obs-FWS.
2.4. Common ABNF Tokens
The following ABNF tokens are used elsewhere in this document:
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])
[ "=" [FWS] [ "=" [FWS] ] ]
2.5. Imported ABNF Tokens
The following tokens are imported from other RFCs as noted. Those
RFCs should be considered definitive.
The following tokens are imported from [RFC2821]:
o "Local-part" (implementation warning: this permits quoted strings)
The following tokens are imported from [RFC2822]:
o "field-name" (name of a header field)
o "dot-atom-text" (in the Local-part of an email address)
The following tokens are imported from [RFC2045]:
o "qp-section" (a single line of quoted-printable-encoded text)
o "hex-octet" (a quoted-printable encoded octet)
INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey
the rules of RFC 4234 and must be interpreted accordingly,
particularly as regards case folding.
Other tokens not defined herein are imported from [RFC4234]. These
are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,
The DKIM-Quoted-Printable encoding syntax resembles that described in
Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded
as an "=" followed by two hexadecimal digits from the alphabet
"0123456789ABCDEF" (no lowercase characters permitted) representing
the hexadecimal-encoded integer value of that character. All control
characters (those with values < %x20), 8-bit characters (values >
%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon
(";", %x3B) MUST be encoded. Note that all whitespace, including
SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS
MAY be added at arbitrary locations in order to avoid excessively
long lines; such whitespace is NOT part of the value, and MUST be
removed before decoding.
*(FWS / hex-octet / dkim-safe-char)
; hex-octet is from RFC 2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
; RFC 2049 are also not recommended.
INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-
Printable as defined in RFC 2045 in several important ways:
1. Whitespace in the input text, including CR and LF, must be
encoded. RFC 2045 does not require such encoding, and does
not permit encoding of CR or LF characters that are part of a
CRLF line break.
2. Whitespace in the encoded text is ignored. This is to allow
tags encoded using DKIM-Quoted-Printable to be wrapped as
needed. In particular, RFC 2045 requires that line breaks in
the input be represented as physical line breaks; that is not
the case here.
3. The "soft line break" syntax ("=" as the last non-whitespace
character on the line) does not apply.
4. DKIM-Quoted-Printable does not require that encoded lines be
no more than 76 characters long (although there may be other
requirements depending on the context in which the encoded
text is being used).