7Network Working Group T. Hansen
8Request for Comments: 5585 AT&T Laboratories
9Category: Informational D. Crocker
10 Brandenburg InternetWorking
12 Default Deny Security, Inc.
16 DomainKeys Identified Mail (DKIM) Service Overview
20 This document provides an overview of the DomainKeys Identified Mail
21 (DKIM) service and describes how it can fit into a messaging service.
22 It also describes how DKIM relates to other IETF message signature
23 technologies. It is intended for those who are adopting, developing,
24 or deploying DKIM. DKIM allows an organization to take
25 responsibility for transmitting a message, in a way that can be
26 verified by a recipient. The organization can be the author's, the
27 originating sending site, an intermediary, or one of their agents. A
28 message can contain multiple signatures from the same or different
29 organizations involved with the message. DKIM defines a domain-level
30 digital signature authentication framework for email, using public-
31 key cryptography, with the domain name service as its key server
32 technology (RFC 4871). This permits verification of a responsible
33 organization, as well as the integrity of the message contents. DKIM
34 also enables a mechanism that permits potential email signers to
35 publish information about their email signing practices; this will
36 permit email receivers to make additional assessments about messages.
37 DKIM's authentication of email identity can assist in the global
38 control of "spam" and "phishing".
42 This memo provides information for the Internet community. It does
43 not specify an Internet standard of any kind. Distribution of this
58Hansen, et al. Informational [Page 1]
60RFC 5585 DKIM Service Overview July 2009
65 Copyright (c) 2009 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents in effect on the date of
70 publication of this document (http://trustee.ietf.org/license-info).
71 Please review these documents carefully, as they describe your rights
72 and restrictions with respect to this document.
76 1. Introduction ....................................................3
77 1.1. DKIM's Scope ...............................................4
78 1.2. Prior Work .................................................5
79 1.3. Internet Mail Background ...................................6
80 2. The DKIM Value Proposition ......................................6
81 2.1. Identity Verification ......................................7
82 2.2. Enabling Trust Assessments .................................7
83 2.3. Establishing Message Validity ..............................8
84 3. DKIM Goals ......................................................8
85 3.1. Functional Goals ...........................................9
86 3.2. Operational Goals .........................................10
87 4. DKIM Function ..................................................12
88 4.1. Basic Signing .............................................12
89 4.2. Characteristics of a DKIM Signature .......................12
90 4.3. The Selector Construct ....................................13
91 4.4. Verification ..............................................13
92 4.5. Sub-Domain Assessment .....................................13
93 5. Service Architecture ...........................................14
94 5.1. Administration and Maintenance ............................15
95 5.2. Signing ...................................................16
96 5.3. Verifying .................................................16
97 5.4. Unverified or Unsigned Mail ...............................16
98 5.5. Assessing .................................................17
99 5.6. DKIM Processing within an ADMD ............................17
100 6. Considerations .................................................17
101 6.1. Security Considerations ...................................17
102 6.2. Acknowledgements ..........................................17
103 7. Informative References .........................................18
104 Appendix A. Internet Mail Background .............................20
105 A.1. Core Model ................................................20
106 A.2. Trust Boundaries ..........................................20
107 Index .............................................................22
114Hansen, et al. Informational [Page 2]
116RFC 5585 DKIM Service Overview July 2009
121 This document provides a description of the architecture and
122 functionality for DomainKeys Identified Mail (DKIM), that is, the
123 core mechanism for signing and verifying messages. It is intended
124 for those who are adopting, developing, or deploying DKIM. It will
125 also be helpful for those who are considering extending DKIM, either
126 into other areas of use or to support additional features. This
127 overview does not provide information on threats to DKIM or email or
128 details on the protocol specifics, which can be found in [RFC4686]
129 and [RFC4871], respectively. Because the scope of this overview is
130 restricted to the technical details of signing and verifying using
131 DKIM, it does not explore operational issues, the details of services
132 that DKIM uses, or those that, in turn, use DKIM. Nor does it
133 discuss services that build upon DKIM for enforcement of policies or
134 assessments. The document assumes a background in basic email and
135 network security technology and services.
137 DKIM allows an organization to take responsibility for a message in a
138 way that can be verified by a recipient. The organization can be a
139 direct handler of the message, such as the author's, the originating
140 sending site's, or an intermediary's along the transit path.
141 However, it can also be an indirect handler, such as an independent
142 service that is providing assistance to a direct handler. DKIM
143 defines a domain-level digital signature authentication framework for
144 email through the use of public-key cryptography and using the domain
145 name service as its key server technology [RFC4871]. It permits
146 verification of the signer of a message, as well as the integrity of
147 its contents. DKIM will also provide a mechanism that permits
148 potential email signers to publish information about their email
149 signing practices; this will permit email receivers to make
150 additional assessments of unsigned messages. DKIM's authentication
151 of email identity can assist in the global control of "spam" and
154 Neither this document nor DKIM attempts to provide solutions to the
155 world's problems with spam, phishing, viruses, worms, joe jobs, etc.
156 DKIM provides one basic tool, in what needs to be a large arsenal,
157 for improving basic trust in the Internet mail service. However, by
158 itself, DKIM is not sufficient to that task and this overview does
159 not pursue the issues of integrating DKIM into these larger efforts,
160 beyond a simple reference within a system diagram. Rather, it is a
161 basic introduction to the technology and its use.
170Hansen, et al. Informational [Page 3]
172RFC 5585 DKIM Service Overview July 2009
177 A person or organization has an "identity" -- that is, a
178 constellation of characteristics that distinguish them from any other
179 identity. Associated with this abstraction can be a label used as a
180 reference, or "identifier". This is the distinction between a thing
181 and the name of the thing. DKIM uses a domain name as an identifier,
182 to refer to the identity of a responsible person or organization. In
183 DKIM, this identifier is called the Signing Domain IDentifier (SDID)
184 and is contained in the DKIM-Signature header fields "d=" tag. Note
185 that the same identity can have multiple identifiers.
187 A DKIM signature can be created by a direct handler of a message,
188 such as the message's author or by an intermediary. A signature also
189 can be created by an independent service that is providing assistance
190 to a handler of the message. Whoever does the signing chooses the
191 SDID to be used as the basis for later assessments. Hence, the
192 reputation associated with that domain name might be an additional
193 basis for evaluating whether to trust the message for delivery. The
194 owner of the SDID is declaring that they accept responsibility for
195 the message and can thus be held accountable for it.
197 DKIM is intended as a value-added feature for email. Mail that is
198 not signed by DKIM is handled in the same way as it was before DKIM
199 was defined. The message will be evaluated by established analysis
200 and filtering techniques. (A signing policy can provide additional
201 information for that analysis and filtering.) Over time, widespread
202 DKIM adoption could permit stricter handling of messages that are not
203 signed. However, early benefits do not require this and probably do
206 DKIM has a narrow scope. It is an enabling technology, intended for
207 use in the larger context of determining message legitimacy. This
208 larger context is complex, so it is easy to assume that a component
209 like DKIM, which actually provides only a limited service, instead
210 satisfies the broader set of requirements.
212 By itself, a DKIM signature:
214 o Does not authenticate or verify the contents of the message header
215 or body, such as the author From field, beyond certifying data
216 integrity between the time of signing and the time of verifying.
218 o Does not offer any assertions about the behaviors of the signer.
220 o Does not prescribe any specific actions for receivers to take upon
221 successful signature verification.
226Hansen, et al. Informational [Page 4]
228RFC 5585 DKIM Service Overview July 2009
231 o Does not provide protection after signature verification.
233 o Does not protect against re-sending (replay of) a message that
234 already has a verified signature; therefore, a transit
235 intermediary or a recipient can re-post the message -- that is,
236 post it as a new message -- with the original signature remaining
237 verifiable, even though the new recipient(s) might be different
238 from those who were originally specified by the author.
242 Historically, the IP Address of the system that directly sent the
243 message -- that is, the previous email "hop" -- has been treated as
244 an identity to use for making assessments. For example, see
245 [RFC4408], [RFC4406], and [RFC4407] for some current uses of the
246 sending system's IP Address. The IP Address is obtained via
247 underlying Internet information mechanisms and is therefore trusted
248 to be accurate. Besides having some known security weaknesses, the
249 use of addresses presents a number of functional and operational
250 problems. Consequently, there is a widespread desire to use an
251 identifier that has better correspondence to organizational
252 boundaries. Domain names can satisfy this need.
254 There have been four previous IETF Internet Mail signature standards.
255 Their goals have differed from those of DKIM. PEM and MOSS are only
256 of historical interest.
258 o Privacy Enhanced Mail (PEM) was first published in 1987 [RFC0989].
260 o Pretty Good Privacy (PGP) was developed by Phil Zimmermann and
261 first released in 1991. A later version was standardized as
262 OpenPGP [RFC1991] [RFC2440] [RFC3156] [RFC4880].
264 o PEM eventually transformed into MIME Object Security Services
265 (MOSS) in 1995 [RFC1848].
267 o RSA Security independently developed Secure MIME (S/MIME) to
268 transport a Public Key Cryptographic System (PKCS) #7 data object.
269 It was standardized as [RFC3851].
271 Development of both S/MIME and OpenPGP has continued. While each has
272 achieved a significant user base, neither one has achieved ubiquity
273 in deployment or use.
275 To the extent that other message-signing services might have been
276 adapted to do the job that DKIM is designed to perform, it was felt
277 that repurposing any of those would be more problematic than creating
282Hansen, et al. Informational [Page 5]
284RFC 5585 DKIM Service Overview July 2009
287 a separate service. That said, DKIM only uses cryptographic
288 components that have a long history, including use within some of
289 those other messaging security services.
291 DKIM is differentiated by its reliance on an identifier that is
292 specific to DKIM use.
294 DKIM also has a distinctive approach for distributing and vouching
295 for keys. It uses a key-centric, public-key management scheme,
296 rather than the more typical approaches based on a certificate in the
297 styles of Kohnfelder (X.509) [Kohnfelder] or Zimmermann (web of
298 trust) [WebofTrust]. For DKIM, the owner of the SDID asserts the
299 validity of a key, rather than having the validity of the key
300 attested to by a trusted third party, often including other
301 assertions, such as a quality assessment of the key's owner. DKIM
302 treats quality assessment as an independent, value-added service,
303 beyond the initial work of deploying a signature verification
306 Further, DKIM's key management is provided by adding information
307 records to the existing Domain Name System (DNS) [RFC1034], rather
308 than requiring deployment of a new query infrastructure. This
309 approach has significant operational advantages. First, it avoids
310 the considerable barrier of creating a new global infrastructure;
311 hence, it leverages a global base of administrative experience and
312 highly reliable distributed operation. Second, the technical aspect
313 of the DNS is already known to be efficient. Any new service would
314 have to undergo a period of gradual maturation, with potentially
315 problematic early-stage behaviors. By (re-)using the DNS, DKIM
316 avoids these growing pains.
3181.3. Internet Mail Background
320 The basic Internet email service has evolved extensively over its
321 several decades of continuous operation. Its modern architecture
322 comprises a number of specialized components. A discussion about
323 Mail User Agents (MUAs), Mail Handling Services (MHSs), Mail Transfer
324 Agents (MTAs), Mail Submission Agents (MSAs), Mail Delivery Agents
325 (MDAs), Mail Service Providers (MSPs), Administrative Management
326 Domains (ADMDs), Mediators, and their relationships can be found in
3292. The DKIM Value Proposition
331 The nature and origins of a message often are falsely stated. Such
332 misrepresentations may be employed for legitimate or nefarious
333 reasons. DKIM provides a foundation for distinguishing legitimate
334 mail, and thus a means of associating a verifiable identifier with a
338Hansen, et al. Informational [Page 6]
340RFC 5585 DKIM Service Overview July 2009
343 message. Given the presence of that identifier, a receiver can make
344 decisions about further handling of the message, based upon
345 assessments of the identity that is associated with the identifier.
347 Receivers who successfully verify a signature can use information
348 about the signer as part of a program to limit spam, spoofing,
349 phishing, or other undesirable behaviors. DKIM does not, itself,
350 prescribe any specific actions by the recipient; rather, it is an
351 enabling technology for services that do.
353 These services will typically:
355 1. Determine a verified identity as taking responsibility for the
356 message, if possible.
358 2. Evaluate the trustworthiness of this/these identities.
360 The role of DKIM is to perform the first of these; DKIM is an enabler
3632.1. Identity Verification
365 Consider an attack made against an organization or against customers
366 of an organization. The name of the organization is linked to
367 particular Internet domain names (identifiers). Attackers can
368 leverage using either a legitimate domain name, one without
369 authorization, or a "cousin" name that is similar to one that is
370 legitimate, but is not controlled by the target organization. An
371 assessment service that uses DKIM can differentiate between a domain
372 (SDID) used by a known organization and a domain used by others. As
373 such, DKIM performs the positive step of identifying messages
374 associated with verifiable identities, rather than the negative step
375 of identifying messages with problematic use of identities. Whether
376 a verified identity belongs to a Good Actor or a Bad Actor is a
377 question for later stages of assessment.
3792.2. Enabling Trust Assessments
381 Email receiving services are faced with a basic decision: whether to
382 accept and deliver a newly arrived message to the indicated
383 recipient? That is, does the receiving service trust that the
384 message is sufficiently "safe" to be viewed? For the modern
385 Internet, most receiving services have an elaborate engine that
386 formulates this quality assessment. These engines take a variety of
387 information as input to the decision, such as from reputation lists
388 and accreditation services. As the engine processes information, it
389 raises or lowers its trust assessment for the message.
394Hansen, et al. Informational [Page 7]
396RFC 5585 DKIM Service Overview July 2009
399 In order to formulate reputation information, an accurate, stable
400 identifier is needed. Otherwise, the information might not pertain
401 to the identified organization's own actions. When using an IP
402 Address, accuracy is based on the belief that the underlying Internet
403 infrastructure supplies an accurate address. When using domain-based
404 reputation data, some other form of verification is needed, since it
405 is not supplied independently by the infrastructure.
407 DKIM satisfies this requirement by declaring a valid "responsible"
408 identity -- referenced through the SDID -- about which the engine can
409 make quality assessments and by using a digital signature to ensure
410 that use of the identifier is authorized. However, by itself, a
411 valid DKIM signature neither lowers nor raises the level of trust
412 associated with the message, but it enables other mechanisms to be
415 An organization might build upon its use of DKIM by publishing
416 information about its Signing Practices (SP). This could permit
417 detecting some messages that purport to be associated with a domain,
418 but which are not. As such, an SP can cause the trust assessment to
419 be reduced, or leave it unchanged.
4212.3. Establishing Message Validity
423 Though man-in-the-middle attacks are historically rare in email, it
424 is nevertheless theoretically possible for a message to be modified
425 during transit. An interesting side effect of the cryptographic
426 method used by DKIM is that it is possible to be certain that a
427 signed message (or, if l= is used, the signed portion of a message)
428 has not been modified between the time of signing and the time of
429 verifying. If it has been changed in any way, then the message will
430 not be verified successfully with DKIM.
432 As described above, this validity neither lowers nor raises the level
433 of trust associated with the message. If it was an untrustworthy
434 message when initially sent, the verifier can be certain that the
435 message will be equally untrustworthy upon receipt and successful
440 DKIM adds an end-to-end authentication capability to the existing
441 email transfer infrastructure. That is, there can be multiple email
442 relaying hops between signing and verifying. Hence, it defines a
443 mechanism that only needs to be supported by the signer and the
450Hansen, et al. Informational [Page 8]
452RFC 5585 DKIM Service Overview July 2009
455 verifier, rather than any of the functional components along the
456 handling path. This motivates functional goals about the
457 authentication itself and operational goals about its integration
458 with the rest of the Internet email service.
4623.1.1. Use Domain-Level Granularity for Assurance
464 DKIM provides accountability at the coarse granularity of an
465 organization or, perhaps, a department. An existing construct that
466 enables this granularity is the Domain Name [RFC1034]. DKIM binds a
467 signing key record to a Domain Name as the SDID. Further benefits of
468 using domain names include simplifying key management, enabling
469 signing by the infrastructure as opposed to the MUA, and reducing
472 Contrast this with OpenPGP and S/MIME, which associate verification
473 with individual authors, using their full email addresses.
4753.1.2. Implementation Locality
477 Any party, anywhere along the transit path, can implement DKIM
478 signing. Its use is not confined to particular systems, such as the
479 author's MUA or the inbound boundary MTA, and there can be more than
480 one signature per message.
4823.1.3. Allow Delegation of Signing to Independent Parties
484 Different parties have different roles in the process of email
485 exchange. Some are easily visible to end users and others are
486 primarily visible to operators of the service. DKIM was designed to
487 support signing by any of these different parties and to permit them
488 to sign with any domain name that they deem appropriate (and for
489 which they hold authorized signing keys). As an example, an
490 organization that creates email content often delegates portions of
491 its processing or transmission to an outsourced group. DKIM supports
492 this mode of activity, in a manner that is not normally visible to
493 end users. Similarly, a reputation provider can delegate a signing
494 key for a domain under the control of the provider, to be used by an
495 organization for which the provider is prepared to vouch.
4973.1.4. Distinguish the Core Authentication Mechanism from Its
500 An authenticated identity can be subject to a variety of assessment
501 policies, either ad hoc or standardized. DKIM separates basic
502 authentication from assessment. The only semantics inherent to a
506Hansen, et al. Informational [Page 9]
508RFC 5585 DKIM Service Overview July 2009
511 DKIM signature are that the signer is asserting some kind of
512 responsibility for the message. Any interpretation of this kind of
513 responsibility is the job of services building on DKIM, but the
514 details are beyond the scope of that core. One such mechanism might
515 assert a relationship between the SDID and the author, as specified
516 in the rfc5322.From: header field's domain identity. Another might
517 specify how to treat an unsigned message with that rfc5322.From:
5203.1.5. Retain Ability to Have Anonymous Email
522 The ability to send a message that does not identify its author is
523 considered to be a valuable quality of the current email service that
524 needs to be retained. DKIM is compatible with this goal since it
525 permits authentication of the email system operator, rather than the
526 content author. If it is possible to obtain effectively anonymous
527 accounts at example.com, knowing that a message definitely came from
528 example.com does not threaten the anonymity of the user who authored
5313.2. Operational Goals
5333.2.1. Make Presence of Signature Transparent to Non-Supporting
536 In order to facilitate incremental adoption, DKIM is designed to be
537 transparent to recipients that do not support it. A DKIM signature
538 does not "get in the way" for such recipients.
540 Contrast this with S/MIME and OpenPGP, which modify the message body.
541 Hence, their presence is potentially visible to email recipients,
542 whose user software needs to process the associated constructs.
5443.2.2. Treat Verification Failure the Same as No Signature Present
546 DKIM must also be transparent to existing assessment mechanisms.
547 Consequently, a DKIM signature verifier is to treat messages with
548 signatures that fail as if they were unsigned. Hence, the message
549 will revert to normal handling, through the receiver's existing
550 filtering mechanisms. Thus, DKIM specifies that an assessing site is
551 not to take a message that has a broken signature and treat it any
552 differently than if the signature weren't there.
554 Contrast this with OpenPGP and S/MIME, which were designed for strong
555 cryptographic protection. This included treating verification
556 failure as message failure.
562Hansen, et al. Informational [Page 10]
564RFC 5585 DKIM Service Overview July 2009
5673.2.3. Permit Incremental Adoption for Incremental Benefit
569 DKIM can be used by any two organizations that exchange email and
570 implement DKIM; it does not require adoption within the open
571 Internet's email infrastructure. In the usual manner of "network
572 effects", the benefits of DKIM increase as its adoption increases.
573 Although this mechanism can be used in association with independent
574 assessment services, such services are not essential in order to
575 obtain initial benefit. For example, DKIM allows (possibly large)
576 pairwise sets of email providers and spam filtering companies to
577 distinguish mail that is associated with a known organization, versus
578 mail that might deceptively purport to have the affiliation. This in
579 turn allows the development of "whitelist" schemes whereby
580 authenticated mail from a known source with good reputation is
581 allowed to bypass some anti-abuse filters.
583 In effect, the email receiver can use their set of known
584 relationships to generate their own reputation data. This works
585 particularly well for traffic between large sending providers and
586 large receiving providers. However, it also works well for any
587 operator, public or private, that has mail traffic dominated by
588 exchanges among a stable set of organizations.
590 Management of email delivery problems currently represents a
591 significant pain point for email administrators at every point on the
592 mail transit path. Administrators who have deployed DKIM
593 verification have an incentive to encourage senders (who might
594 subsequently complain that their email is not being delivered) to use
5973.2.4. Minimize the Amount of Required Infrastructure
599 In order to allow early adopters to gain early benefit, DKIM makes no
600 changes to the core Internet Mail service and, instead, can provide a
601 useful benefit for any individual pair of signers and verifiers who
602 are exchanging mail. Similarly, DKIM's reliance on the Domain Name
603 System greatly reduces the amount of new administrative
604 infrastructure that is needed across the open Internet.
6063.2.5. Permit a Wide Range of Deployment Choices
608 DKIM can be deployed at a variety of places within an organization's
609 email service. This affords flexibility in terms of who administers
610 its use, as well as what traffic carries a DKIM signature. For
611 example, employing DKIM at an outbound boundary MTA will mean that it
612 is administered by the organization's central IT department and that
613 internal messages are not signed.
618Hansen, et al. Informational [Page 11]
620RFC 5585 DKIM Service Overview July 2009
625 DKIM has a very constrained set of capabilities, primarily targeting
626 email while it is in transit from an author to a set of recipients.
627 It associates verifiable information with a message, especially a
628 responsible identity. When a message does not have a valid signature
629 associated with the author, a DKIM SP will permit the domain name of
630 the author to be used for obtaining information about their signing
635 With the DKIM signature mechanism, a signer chooses an SDID, performs
636 digital signing on the message, and adds the signature information
637 using a DKIM header field. A verifier obtains the domain name and
638 the "selector" from the DKIM header field, obtains the public key
639 associated with the name, and verifies the signature.
641 DKIM permits any domain name to be used as the SDID, and supports
642 extensible choices for various algorithms. As is typical for
643 Internet standards, there is a core set of algorithms that all
644 implementations are required to support, in order to guarantee basic
647 DKIM permits restricting the use of a signature key to signing
648 messages for particular types of services, such as only for a single
649 source of email. This is intended to be helpful when delegating
650 signing authority, such as to a particular department or to a third-
651 party outsourcing service.
653 With DKIM, the signer explicitly lists the headers that are signed,
654 such as From:, Date:, and Subject:. By choosing the minimal set of
655 headers needed, the signature is likely to be considerably more
656 robust against the handling vagaries of intermediary MTAs.
6584.2. Characteristics of a DKIM Signature
660 A DKIM signature applies to the message body and selected header
661 fields. The signer computes a hash of the selected header fields and
662 another hash of the body. The signer then uses a private key to
663 cryptographically encode this information, along with other signing
664 parameters. Signature information is placed into DKIM-Signature:, a
665 new [RFC5322] message header field.
674Hansen, et al. Informational [Page 12]
676RFC 5585 DKIM Service Overview July 2009
6794.3. The Selector Construct
681 The key for a signature is associated with an SDID. That domain name
682 provides the complete identity used for making assessments about the
683 signer. (The DKIM specification does not give any guidance on how to
684 do an assessment.) However, this name is not sufficient for making a
685 DNS query to obtain the key needed to verify the signature.
687 A single SDID can have multiple signing keys and/or multiple
688 potential signers. To support this, DKIM identifies a particular
689 signature as using a combination of the SDID and an added field,
690 called the "selector", specified in a separate DKIM-Signature: header
693 NOTE: The semantics of the selector (if any) are strictly reserved
694 to the signer and is to be treated as an opaque string by all
695 other parties. If verifiers were to employ the selector as part
696 of an assessment mechanism, then there would be no remaining
697 mechanism for making a transition from an old, or compromised, key
702 After a message has been signed, any agent in the message transit
703 path can verify the signature to determine that the owner of the SDID
704 took responsibility for the message. Message recipients can verify
705 the signature by querying the DNS for the signer's domain directly,
706 to retrieve the appropriate public key, and thereby confirm that the
707 message was signed by a party in possession of the private key for
708 the SDID. Typically, verification will be done by an agent in the
709 Administrative Management Domain (ADMD) of the message recipient.
7114.5. Sub-Domain Assessment
713 Signers often need to support multiple assessments about their
714 organization, such as to distinguish one type of message from
715 another, or one portion of the organization from another. To permit
716 assessments that are independent, one method is for an organization
717 to use different sub-domains as the SDID tag, such as
718 "transaction.example.com" versus "newsletter.example.com", or
719 "productA.example.com" versus "productB.example.com". These can be
720 entirely separate from the rfc5322.From header field domain.
730Hansen, et al. Informational [Page 13]
732RFC 5585 DKIM Service Overview July 2009
7355. Service Architecture
737 DKIM uses external service components, such as for key retrieval and
738 relaying email. This specification defines an initial set, using DNS
739 and SMTP, for basic interoperability.
743 +--------+ +--------------------------------+
744 | Private| | ORIGINATING OR RELAYING ADMD |
745 | Key +...>| Sign Message with SDID |
746 | Store | +---------------+----------------+
749 +--------+ | +-----------+
750 | Public | +--------------------------------+ | Remote |
751 | Key | | RELAYING OR DELIVERING ADMD | | Sender |
752 | Store | | Message Signed? | | Practices |
753 +----+---+ +-----+--------------------+-----+ +-----+-----+
756 . +-------------+ | .
757 +.......>| Verify +--------+ | .
759 +------+------+ | | .
762 +-------------+ | | .
764 +.......>| Assessments | | | .
766 . +-----+--+----+ +-------+ .
767 . | | / Check \<............+
768 . | +-------->/ Signing \
769 . | / Practices \<..........+
770 . | +-------+-------+ .
773 +----+--------+ | +-----------+ +------+-----+
774 |Reputation/ | | | Message | | Local Info |
775 |Accreditation| +----------->| Filtering | | on Sender |
776 |Info | | Engine | | Practices |
777 +-------------+ +-----------+ +------------+
779 Figure 1: DKIM Service Architecture
786Hansen, et al. Informational [Page 14]
788RFC 5585 DKIM Service Overview July 2009
791 As shown in Figure 1, basic message processing is divided between a
792 signing Administrative Management Domain (ADMD) and a verifying ADMD.
793 At its simplest, this is between the originating ADMD and the
794 delivering ADMD, but can involve other ADMDs in the handling path.
796 signing: Signing is performed by an authorized module within the
797 signing ADMD and uses private information from the Key Store, as
798 discussed below. Within the originating ADMD, this might be
799 performed by the MUA, MSA, or an MTA.
801 verifying: verifying is performed by an authorized module within
802 the verifying ADMD. Within a delivering ADMD, verifying might be
803 performed by an MTA, MDA, or MUA. The module verifies the
804 signature or determines whether a particular signature was
805 required. Verifying the signature uses public information from
806 the Key Store. If the signature passes, reputation information is
807 used to assess the signer and that information is passed to the
808 message filtering system. If the signature fails or there is no
809 signature using the author's domain, information about signing
810 practices related to the author can be retrieved remotely and/or
811 locally, and that information is passed to the message filtering
814 If a message has more than one valid signature, the order in which
815 the signers are assessed and the interactions among the assessments
816 are not defined by the DKIM specification.
8185.1. Administration and Maintenance
820 A number of tables and services are used to provide external
821 information. Each of these introduces administration and maintenance
824 Key Store: DKIM uses public-/private-key (asymmetric) cryptography.
825 The signer users a private key and the verifier uses the
826 corresponding public key. The current DKIM Signing specification
827 provides for querying the Domain Names Service (DNS), to permit a
828 verifier to obtain the public key. The signing organization
829 therefore needs to have a means of adding a key to the DNS, for
830 every selector/SDID combination. Further, the signing
831 organization needs policies for distributing and revising keys.
833 Reputation/Accreditation: If a message contains a valid signature,
834 then the verifier can evaluate the associated domain name's
835 reputation, in order to determine appropriate delivery or display
836 options for that message. Quality assessment information, which
842Hansen, et al. Informational [Page 15]
844RFC 5585 DKIM Service Overview July 2009
847 is associated with a domain name, comes in many forms and from
848 many sources. DKIM does not define assessment services. Its
849 relevance to them is to provide a verified domain name, upon which
850 assessments can be made.
852 Signing Practices (SP): Separate from determining the validity of a
853 signature, and separate from assessing the reputation of the
854 organization that is associated with the signed identity, there is
855 an opportunity to determine any organizational practices
856 concerning a domain name. Practices can range widely. They can
857 be published by the owner of the domain or they can be maintained
858 by the evaluating site. They can pertain to the use of the domain
859 name, such as whether it is used for signing messages, whether all
860 mail having that domain name in the author rfc5322.From: header
861 field is signed, or even whether the domain owner recommends
862 discarding messages in the absence of an appropriate signature.
863 The statements of practice are made at the level of a domain name,
864 and are distinct from assessments made about particular messages,
865 as occur in a Message Filtering Engine. Such assessments of
866 practices can provide useful input for the Message Filtering
867 Engine's determination of message handling. As practices are
868 defined, each domain name owner needs to consider what information
869 to publish. The nature and degree of checking practices, if any
870 are performed, is optional to the evaluating site and is strictly
871 a matter of local policy.
875 Signing can be performed by a component of the ADMD that creates the
876 message, and/or within any ADMD along the relay path. The signer
877 uses the appropriate private key that is associated with the SDID.
881 Verification can be performed by any functional component along the
882 relay and delivery path. Verifiers retrieve the public key based
883 upon the parameters stored in the message.
8855.4. Unverified or Unsigned Mail
887 Messages lacking a valid author signature (a signature associated
888 with the author of the message as opposed to a signature associated
889 with an intermediary) can prompt a query for any published "signing
890 practices" information, as an aid in determining whether the author
891 information has been used without authorization.
898Hansen, et al. Informational [Page 16]
900RFC 5585 DKIM Service Overview July 2009
905 Figure 1 shows the verified identity as being used to assess an
906 associated reputation, but it could be applied to other tasks, such
907 as management tracking of mail. Local policy guidelines may cause
908 signing practices to be checked or the message may be sent directly
909 to the message Filtering Engine.
911 A popular use of reputation information is as input to a Filtering
912 Engine that decides whether to deliver -- and possibly whether to
913 specially mark -- a message. Filtering Engines have become complex
914 and sophisticated. Their details are outside of the scope of DKIM,
915 other than the expectation that the verified identity produced by
916 DKIM can accumulate its own reputation, and will be added to the
917 varied soup of rules used by the engines. The rules can cover signed
918 messages and can deal with unsigned messages from a domain, if the
919 domain has published information about its practices.
9215.6. DKIM Processing within an ADMD
923 It is expected that the most common venue for a DKIM implementation
924 will be within the infrastructures of the authoring organization's
925 outbound service and the receiving organization's inbound service,
926 such as a department or a boundary MTA. DKIM can be implemented in
927 an author's or recipient's MUA, but this is expected to be less
928 typical, since it has higher administration and support costs.
930 A Mediator is an MUA that receives a message and can repost a
931 modified version of it, such as to a mailing list. A DKIM signature
932 can survive some types of modifications through this process.
933 Furthermore, the Mediator can add its own signature. This can be
934 added by the Mediator software itself, or by any outbound component
935 in the Mediator's ADMD.
9396.1. Security Considerations
941 The security considerations of the DKIM protocol are described in the
942 DKIM base specification [RFC4871], with [RFC4686] as their basis.
946 Many people contributed to the development of the DomainKeys
947 Identified Mail and the effort of the DKIM Working Group is
948 gratefully acknowledged. In particular, we would like to thank Jim
949 Fenton for his extensive feedback diligently provided on every
950 version of this document.
954Hansen, et al. Informational [Page 17]
956RFC 5585 DKIM Service Overview July 2009
9597. Informative References
961 [Kohnfelder] Kohnfelder, L., "Towards a Practical Public-key
962 Cryptosystem", May 1978.
964 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy
965 enhancement for Internet electronic mail: Part I:
966 Message encipherment and authentication procedures",
967 RFC 989, February 1987.
969 [RFC1034] Mockapetris, P., "Domain names - concepts and
970 facilities", STD 13, RFC 1034, November 1987.
972 [RFC1113] Linn, J., "Privacy enhancement for Internet electronic
973 mail: Part I - message encipherment and authentication
974 procedures", RFC 1113, August 1989.
976 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed,
977 "MIME Object Security Services", RFC 1848,
980 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP
981 Message Exchange Formats", RFC 1991, August 1996.
983 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
984 "OpenPGP Message Format", RFC 2440, November 1998.
986 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
987 "MIME Security with OpenPGP", RFC 3156, August 2001.
989 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
990 Extensions (S/MIME) Version 3.1 Message Specification",
993 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating
994 E-Mail", RFC 4406, April 2006.
996 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
997 Messages", RFC 4407, April 2006.
999 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
1000 for Authorizing Use of Domains in E-Mail, Version 1",
1001 RFC 4408, April 2006.
1003 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
1004 Identified Mail (DKIM)", RFC 4686, September 2006.
1010Hansen, et al. Informational [Page 18]
1012RFC 5585 DKIM Service Overview July 2009
1015 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
1016 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
1017 Signatures", RFC 4871, May 2007.
1019 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
1020 R. Thayer, "OpenPGP Message Format", RFC 4880,
1023 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1026 [WebofTrust] Network Associates, Inc. and its Affiliated Companies,
1027 "How PGP works, in Introduction to Cryptography", 1999,
1028 <http://www.pgpi.org/doc/pgpintro/>.
1066Hansen, et al. Informational [Page 19]
1068RFC 5585 DKIM Service Overview July 2009
1071Appendix A. Internet Mail Background
1075 Internet Mail is split between the user world, in the form of Mail
1076 User Agents (MUA), and the transmission world, in the form of the
1077 Mail Handling Service (MHS) composed of Mail Transfer Agents (MTA).
1078 The MHS is responsible for accepting a message from one user, the
1079 author, and delivering it to one or more other users, the recipients.
1080 This creates a virtual MUA-to-MUA exchange environment. The first
1081 component of the MHS is called the Mail Submission Agent (MSA) and
1082 the last is called the Mail Delivery Agent (MDA).
1084 An email Mediator is both an inbound MDA and outbound MSA. It takes
1085 delivery of a message, makes changes appropriate to its service, and
1086 then reposts it for further distribution. Typically, the new message
1087 will retain the original rfc5322.From: header field. A mailing list
1088 is a common example of a Mediator.
1090 The modern Internet Mail service is marked by many independent
1091 operators, many different components for providing users with service
1092 and many other components for performing message transfer.
1093 Consequently, it is necessary to distinguish administrative
1094 boundaries that surround sets of functional components, which are
1095 subject to coherent operational policies.
1097 As elaborated on below, every MSA is a candidate for signing using
1098 DKIM, and every MDA is a candidate for doing DKIM verification.
1100A.2. Trust Boundaries
1102 Operation of Internet Mail services is apportioned to different
1103 providers (or operators). Each can be composed of an independent
1104 ADministrative Management Domain (ADMD). An ADMD operates with an
1105 independent set of policies and interacts with other ADMDs according
1106 to differing types and amounts of trust. Examples include an end
1107 user operating a desktop client that connects to an independent email
1108 service, a department operating a submission agent or a local Relay,
1109 an organization's IT group that operates enterprise Relays, and an
1110 ISP operating a public shared email service.
1112 Each of these can be configured into many combinations of
1113 administrative and operational relationships, with each ADMD
1114 potentially having a complex arrangement of functional components.
1115 Figure 2 depicts the relationships among ADMDs. Perhaps the most
1116 salient aspect of an ADMD is the differential trust that determines
1117 its policies for activities within the ADMD, versus those involving
1118 interactions with other ADMDs.
1122Hansen, et al. Informational [Page 20]
1124RFC 5585 DKIM Service Overview July 2009
1127 Basic types of ADMDs include:
1129 Edge: Independent transfer services, in networks at the edge of
1130 the Internet Mail service.
1132 User: End-user services. These might be subsumed under an Edge
1133 service, such as is common for web-based email access.
1135 Transit: These are Mail Service Providers (MSP) offering value-
1136 added capabilities for Edge ADMDs, such as aggregation and
1139 Note that Transit services are quite different from packet-level
1140 transit operation. Whereas end-to-end packet transfers usually go
1141 through intermediate routers, email exchange across the open Internet
1142 often is directly between the Edge ADMDs, at the email level.
1144 +--------+ +--------+ +--------+
1145 | ADMD#1 | | ADMD#3 | | ADMD#4 |
1146 | ------ | | ------ | | ------ |
1147 | | +----------------------->| | | |
1148 | User | | |--Edge--+--->|--User |
1149 | | | | +--->| | | |
1150 | V | | | +--------+ +--------+
1152 | | | +----------+ |
1153 +--------+ | | ADMD#2 | |
1156 +--->|-Transit--+---+
1160 Figure 2: ADministrative Management Domains (ADMD) Example
1162 In Figure 2, ADMD numbers 1 and 2 are candidates for doing DKIM
1163 signing, and ADMD numbers 2, 3, and 4 are candidates for doing DKIM
1166 The distinction between Transit network and Edge network transfer
1167 services is primarily significant because it highlights the need for
1178Hansen, et al. Informational [Page 21]
1180RFC 5585 DKIM Service Overview July 2009
1183 concern over interaction and protection between independent
1184 administrations. The interactions between functional components
1185 within a single ADMD are subject to the policies of that domain.
1186 Although any pair of ADMDs can arrange for whatever policies they
1187 wish, Internet Mail is designed to permit inter-operation without
1190 Common ADMD examples are:
1192 Enterprise Service Providers:
1194 Operators of an organization's internal data and/or mail
1197 Internet Service Providers:
1199 Operators of underlying data communication services that, in
1200 turn, are used by one or more Relays and Users. It is not
1201 necessarily their job to perform email functions, but they
1202 can, instead, provide an environment in which those
1203 functions can be performed.
1205 Mail Service Providers:
1207 Operators of email services, such as for end users, or
1214 Administrative Management Domain 6
1218 DKIM-Signature 12-13
1224 infrastructure 5-6, 8-11, 17
1227 Mail Delivery Agent 6
1228 Mail Handling Service 6
1229 Mail Service Provider 6
1230 Mail Submission Agent 6
1234Hansen, et al. Informational [Page 22]
1236RFC 5585 DKIM Service Overview July 2009
1239 Mail Transfer Agent 6
1243 MIME Object Security Services 5
1256 Pretty Good Privacy 5
1257 Privacy Enhanced Mail 5
1266 verification 4, 7-8, 10-11, 13, 16, 20-21
1290Hansen, et al. Informational [Page 23]
1292RFC 5585 DKIM Service Overview July 2009
1300 Middletown, NJ 07748
1303 EMail: tony+dkimov@maillennium.att.com
1307 Brandenburg InternetWorking
1312 EMail: dcrocker@bbiw.net
1315 Phillip Hallam-Baker
1316 Default Deny Security, Inc.
1318 EMail: phillip@hallambaker.com
1346Hansen, et al. Informational [Page 24]