7Internet Engineering Task Force (IETF) T. Hansen
8Request for Comments: 5863 AT&T Laboratories
9Category: Informational E. Siegel
10ISSN: 2070-1721 Consultant
12 Default Deny Security, Inc.
14 Brandenburg InternetWorking
18 DomainKeys Identified Mail (DKIM)
19 Development, Deployment, and Operations
23 DomainKeys Identified Mail (DKIM) allows an organization to claim
24 responsibility for transmitting a message, in a way that can be
25 validated by a recipient. The organization can be the author's, the
26 originating sending site, an intermediary, or one of their agents. A
27 message can contain multiple signatures, from the same or different
28 organizations involved with the message. DKIM defines a domain-level
29 digital signature authentication framework for email, using public
30 key cryptography and using the domain name service as its key server
31 technology. This permits verification of a responsible organization,
32 as well as the integrity of the message content. DKIM will also
33 provide a mechanism that permits potential email signers to publish
34 information about their email signing practices; this will permit
35 email receivers to make additional assessments about messages.
36 DKIM's authentication of email identity can assist in the global
37 control of "spam" and "phishing". This document provides
38 implementation, deployment, operational, and migration considerations
43 This document is not an Internet Standards Track specification; it is
44 published for informational purposes.
46 This document is a product of the Internet Engineering Task Force
47 (IETF). It represents the consensus of the IETF community. It has
48 received public review and has been approved for publication by the
49 Internet Engineering Steering Group (IESG). Not all documents
50 approved by the IESG are a candidate for any level of Internet
51 Standard; see Section 2 of RFC 5741.
58Hansen, et al. Informational [Page 1]
60RFC 5863 DKIM Development/Deployment/Operations May 2010
63 Information about the current status of this document, any errata,
64 and how to provide feedback on it may be obtained at
65 http://www.rfc-editor.org/info/rfc5863.
69 Copyright (c) 2010 IETF Trust and the persons identified as the
70 document authors. All rights reserved.
72 This document is subject to BCP 78 and the IETF Trust's Legal
73 Provisions Relating to IETF Documents
74 (http://trustee.ietf.org/license-info) in effect on the date of
75 publication of this document. Please review these documents
76 carefully, as they describe your rights and restrictions with respect
77 to this document. Code Components extracted from this document must
78 include Simplified BSD License text as described in Section 4.e of
79 the Trust Legal Provisions and are provided without warranty as
80 described in the Simplified BSD License.
82 This document may contain material from IETF Documents or IETF
83 Contributions published or made publicly available before November
84 10, 2008. The person(s) controlling the copyright in some of this
85 material may not have granted the IETF Trust the right to allow
86 modifications of such material outside the IETF Standards Process.
87 Without obtaining an adequate license from the person(s) controlling
88 the copyright in such materials, this document may not be modified
89 outside the IETF Standards Process, and derivative works of it may
90 not be created outside the IETF Standards Process, except to format
91 it for publication as an RFC or to translate it into languages other
96 1. Introduction ....................................................4
97 2. Using DKIM as Part of Trust Assessment ..........................4
98 2.1. A Systems View of Email Trust Assessment ...................4
99 2.2. Choosing a DKIM Tag for the Assessment Identifier ..........6
100 2.3. Choosing the Signing Domain Name ...........................8
101 2.4. Recipient-Based Assessments ...............................10
102 2.5. Filtering .................................................12
103 3. DKIM Key Generation, Storage, and Management ...................15
104 3.1. Private Key Management: Deployment and Ongoing
105 Operations ................................................16
106 3.2. Storing Public Keys: DNS Server Software Considerations ...17
107 3.3. Per-User Signing Key Management Issues ....................18
108 3.4. Third-Party Signer Key Management and Selector
109 Administration ............................................19
110 3.5. Key Pair / Selector Life Cycle Management .................19
114Hansen, et al. Informational [Page 2]
116RFC 5863 DKIM Development/Deployment/Operations May 2010
119 4. Signing ........................................................21
120 4.1. DNS Records ...............................................21
121 4.2. Signing Module ............................................21
122 4.3. Signing Policies and Practices ............................22
123 5. Verifying ......................................................23
124 5.1. Intended Scope of Use .....................................23
125 5.2. Signature Scope ...........................................23
126 5.3. Design Scope of Use .......................................24
127 5.4. Inbound Mail Filtering ....................................24
128 5.5. Messages Sent through Mailing Lists and Other
129 Intermediaries ............................................25
130 5.6. Generation, Transmission, and Use of Results Headers ......25
131 6. Taxonomy of Signatures .........................................26
132 6.1. Single Domain Signature ...................................26
133 6.2. Parent Domain Signature ...................................27
134 6.3. Third-Party Signature .....................................27
135 6.4. Using Trusted Third-Party Senders .........................29
136 6.5. Multiple Signatures .......................................30
137 7. Example Usage Scenarios ........................................31
138 7.1. Author's Organization - Simple ............................32
139 7.2. Author's Organization - Differentiated Types of Mail ......32
140 7.3. Author Domain Signing Practices ...........................32
141 7.4. Delegated Signing .........................................34
142 7.5. Independent Third-Party Service Providers .................35
143 7.6. Mail Streams Based on Behavioral Assessment ...............35
144 7.7. Agent or Mediator Signatures ..............................36
145 8. Usage Considerations ...........................................36
146 8.1. Non-Standard Submission and Delivery Scenarios ............36
147 8.2. Protection of Internal Mail ...............................37
148 8.3. Signature Granularity .....................................38
149 8.4. Email Infrastructure Agents ...............................39
150 8.5. Mail User Agent ...........................................40
151 9. Security Considerations ........................................41
152 10. Acknowledgements ..............................................41
153 11. References ....................................................42
154 11.1. Normative References .....................................42
155 11.2. Informative References ...................................42
156 Appendix A. Migration Strategies .................................43
157 A.1. Migrating from DomainKeys .................................43
158 A.2. Migrating Hash Algorithms .................................48
159 A.3. Migrating Signing Algorithms ..............................49
160 Appendix B. General Coding Criteria for Cryptographic
161 Applications .........................................50
170Hansen, et al. Informational [Page 3]
172RFC 5863 DKIM Development/Deployment/Operations May 2010
177 DomainKeys Identified Mail (DKIM) allows an organization to claim
178 responsibility for transmitting a message, in a way that can be
179 validated by a recipient. This document provides practical tips for
180 those who are developing DKIM software, mailing list managers,
181 filtering strategies based on the output from DKIM verification, and
182 DNS servers; those who are deploying DKIM software, keys, mailing
183 list software, and migrating from DomainKeys [RFC4870]; and those who
184 are responsible for the ongoing operations of an email infrastructure
185 that has deployed DKIM.
187 The reader is encouraged to read the DKIM Service Overview document
188 [RFC5585] before this document. More detailed guidance about DKIM
189 and Author Domain Signing Practices (ADSP) can also be found in the
190 protocol specifications [RFC4871], [RFC5617], and [RFC5672].
192 The document is organized around the key concepts related to DKIM.
193 Within each section, additional considerations specific to
194 development, deployment, or ongoing operations are highlighted where
195 appropriate. The possibility of the use of DKIM results as input to
196 a local reputation database is also discussed.
1982. Using DKIM as Part of Trust Assessment
2002.1. A Systems View of Email Trust Assessment
202 DKIM participates in a trust-oriented enhancement to the Internet's
203 email service, to facilitate message handling decisions, such as for
204 delivery and for content display. Trust-oriented message handling
205 has substantial differences from the more established approaches that
206 consider messages in terms of risk and abuse. With trust, there is a
207 collaborative exchange between a willing participant along the
208 sending path and a willing participant at a recipient site. In
209 contrast, the risk model entails independent, unilateral action by
210 the recipient site, in the face of a potentially unknown, hostile,
211 and deceptive sender. This translates into a very basic technical
212 difference: in the face of unilateral action by the recipient and
213 even antagonistic efforts by the sender, risk-oriented mechanisms are
214 based on heuristics, that is, on guessing. Guessing produces
215 statistical results with some false negatives and some false
216 positives. For trust-based exchanges, the goal is the deterministic
217 exchange of information. For DKIM, that information is the one
218 identifier that represents a stream of mail for which an independent
219 assessment is sought (by the signer).
226Hansen, et al. Informational [Page 4]
228RFC 5863 DKIM Development/Deployment/Operations May 2010
231 A trust-based service is built upon a validated Responsible
232 Identifier that labels a stream of mail and is controlled by an
233 identity (role, person, or organization). The identity is
234 acknowledging some degree of responsibility for the message stream.
235 Given a basis for believing that an identifier is being used in an
236 authorized manner, the recipient site can make and use an assessment
237 of the associated identity. An identity can use different
238 identifiers, on the assumption that the different streams might
239 produce different assessments. For example, even the best-run
240 marketing campaigns will tend to produce some complaints that can
241 affect the reputation of the associated identifier, whereas a stream
242 of transactional messages is likely to have a more pristine
245 Determining that the identifier's use is valid is quite different
246 from determining that the content of a message is valid. The former
247 means only that the identifier for the responsible role, person, or
248 organization has been legitimately associated with a message. The
249 latter means that the content of the message can be believed and,
250 typically, that the claimed author of the content is correct. DKIM
251 validates only the presence of the identifier used to sign the
252 message. Even when this identifier is validated, DKIM carries no
253 implication that any of the message content, including the
254 RFC5322.From field [RFC5322], is valid. Surprisingly, this limit to
255 the semantics of a DKIM signature applies even when the validated
256 signing identifier is the same domain name as is used in the
257 RFC5322.From field! DKIM's only claim about message content is that
258 the content cited in the DKIM-Signature: field's h= tag has been
259 delivered without modification. That is, it asserts message content
260 integrity -- between signing and verifying -- not message content
263 As shown in Figure 1, this enhancement is a communication between a
264 responsible role, person, or organization that signs the message and
265 a recipient organization that assesses its trust in the signer. The
266 recipient then makes handling decisions based on a collection of
267 assessments, of which the DKIM mechanism is only a part. In this
268 model, as shown in Figure 1, validation is an intermediary step,
269 having the sole task of passing a validated Responsible Identifier to
270 the Identity Assessor. The communication is of a single Responsible
271 Identifier that the Responsible Identity wishes to have used by the
272 Identity Assessor. The Identifier is the sole, formal input and
273 output value of DKIM signing. The Identity Assessor uses this
274 single, provided Identifier for consulting whatever assessment
275 databases are deemed appropriate by the assessing entity. In turn,
276 output from the Identity Assessor is fed into a Handling Filter
282Hansen, et al. Informational [Page 5]
284RFC 5863 DKIM Development/Deployment/Operations May 2010
287 engine that considers a range of factors, along with this single
288 output value. The range of factors can include ancillary information
289 from the DKIM validation.
291 Identity Assessment covers a range of possible functions. It can be
292 as simple as determining whether the identifier is a member of some
293 list, such as authorized operators or participants in a group that
294 might be of interest for recipient assessment. Equally, it can
295 indicate a degree of trust (reputation) that is to be afforded the
296 actor using that identifier. The extent to which the assessment
297 affects the handling of the message is, of course, determined later,
298 by the Handling Filter.
300 +------+------+ +------+------+
301 | Author | | Recipient |
302 +------+------+ +------+------+
311 +-------------+ Identifier +------+------+
312 | Responsible |. . . . . . . . . . .>| Identity |
313 | Identity | . . | Assessor |
314 +------+------+ . . +-------------+
317 +------------------.-------.--------------------+ | |
318 | +------+------+ . . . > . +-------------+ | | | +-----------+
319 | | Identifier | | Identifier +--|--+ +--+ Assessment|
320 | | Signer +------------->| Validator | | | Databases |
321 | +-------------+ +-------------+ | +-----------+
323 +-----------------------------------------------+
325 Figure 1: Actors in a Trust Sequence Using DKIM
3272.2. Choosing a DKIM Tag for the Assessment Identifier
329 The signer of a message needs to be able to provide precise data and
330 know what that data will mean upon delivery to the Assessor. If
331 there is ambiguity in the choice that will be made on the recipient
332 side, then the sender cannot know what basis for assessment will be
333 used. DKIM has three values that specify identification information
334 and it is easy to confuse their use, although only one defines the
338Hansen, et al. Informational [Page 6]
340RFC 5863 DKIM Development/Deployment/Operations May 2010
343 formal input and output of DKIM, with the other two being used for
344 internal protocol functioning and adjunct purposes, such as auditing
347 The salient values include the s=, d= and i= parameters in the DKIM-
348 Signature: header field. In order to achieve the end-to-end
349 determinism needed for this collaborative exchange from the signer to
350 the assessor, the core model needs to specify what the signer is
351 required to provide to the assessor. The update to RFC 4871
354 DKIM's primary task is to communicate from the Signer to a
355 recipient-side Identity Assessor a single Signing Domain
356 Identifier (SDID) that refers to a responsible identity. DKIM MAY
357 optionally provide a single responsible Agent or User Identifier
358 (AUID)... A receive-side DKIM verifier MUST communicate the
359 Signing Domain Identifier (d=) to a consuming Identity Assessor
360 module and MAY communicate the User Agent Identifier (i=) if
361 present.... To the extent that a receiver attempts to intuit any
362 structured semantics for either of the identifiers, this is a
363 heuristic function that is outside the scope of DKIM's
364 specification and semantics.
366 The single, mandatory value that DKIM supplies as its output is:
368 d= This specifies the "domain of the signing entity". It is a
369 domain name and is combined with the selector to form a DNS
370 query. A receive-side DKIM verifier needs to communicate the
371 Signing Domain Identifier (d=) to a consuming Identity Assessor
372 module and can also communicate the User Agent Identifier (i=)
375 The adjunct values are:
377 s= This tag specifies the selector. It is used to discriminate
378 among different keys that can be used for the same d= domain
379 name. As discussed in Section 4.3 of [RFC5585], "If verifiers
380 were to employ the selector as part of an assessment mechanism,
381 then there would be no remaining mechanism for making a
382 transition from an old, or compromised, key to a new one".
383 Consequently, the selector is not appropriate for use as part
384 or all of the identifier used to make assessments.
386 i= This tag is optional and provides the "[t]he Agent or User
387 Identifier (AUID) on behalf of which the SDID is taking
388 responsibility" [RFC5672]. The identity can be in the syntax
394Hansen, et al. Informational [Page 7]
396RFC 5863 DKIM Development/Deployment/Operations May 2010
399 of an entire email address or only a domain name. The domain
400 name can be the same as for d= or it can be a sub-name of the
403 NOTE: Although the i= identity has the syntax of an email
404 address, it is not required to have those semantics. That is,
405 "the identity of the user" need not be the same as the user's
406 mailbox. For example, the signer might wish to use i= to
407 encode user-related audit information, such as how they were
408 accessing the service at the time of message posting.
409 Therefore, it is not possible to conclude anything from the i=
410 string's (dis)similarity to email addresses elsewhere in the
413 So, i= can have any of these properties:
415 * Be a valid domain when it is the same as d=
417 * Appear to be a subdomain of d= but might not even exist
419 * Look like a mailbox address but might have different semantics
420 and therefore not function as a valid email address
422 * Be unique for each message, such as indicating access details
423 of the user for the specific posting
425 This underscores why the tag needs to be treated as being opaque,
426 since it can represent any semantics, known only to the signer.
428 Hence, i= serves well as a token that is usable like a Web cookie,
429 for return to the signing Administrative Management Domain (ADMD) --
430 such as for auditing and debugging. Of course in some scenarios the
431 i= string might provide a useful adjunct value for additional
432 (heuristic) processing by the Handling Filter.
4342.3. Choosing the Signing Domain Name
436 A DKIM signing entity can serve different roles, such as being the
437 author of content, the operator of the mail service, or the operator
438 of a reputation service that also provides signing services on behalf
439 of its customers. In these different roles, the basis for
440 distinguishing among portions of email traffic can vary. For an
441 entity creating DKIM signatures, it is likely that different portions
442 of its mail will warrant different levels of trust. For example:
444 * Mail is sent for different purposes, such as marketing versus
445 transactional, and recipients demonstrate different patterns of
446 acceptance between these.
450Hansen, et al. Informational [Page 8]
452RFC 5863 DKIM Development/Deployment/Operations May 2010
455 * For an operator of an email service, there often are distinct
456 sub-populations of users warranting different levels of trust
457 or privilege, such as paid versus free users, or users engaged
458 in direct correspondence versus users sending bulk mail.
460 * Mail originating outside an operator's system, such as when it
461 is redistributed by a mailing-list service run by the operator,
462 will warrant a different reputation from mail submitted by
463 users authenticated with the operator.
465 It is therefore likely to be useful for a signer to use different d=
466 subdomain names, for different message traffic streams, so that
467 receivers can make differential assessments. However, too much
468 differentiation -- that is, too fine a granularity of signing domains
469 -- makes it difficult for the receiver to discern a sufficiently
470 stable pattern of traffic for developing an accurate and reliable
471 assessment. So the differentiation needs to achieve a balance.
472 Generally, in a trust system, legitimate signers have an incentive to
473 pick a small stable set of identities, so that recipients and others
474 can attribute reputations to them. The set of these identities a
475 receiver trusts is likely to be quite a bit smaller than the set it
478 The challenge in using additional layers of subdomains is whether the
479 extra granularity will be useful for the Assessor. In fact,
480 excessive levels invite ambiguity: if the Assessor does not take
481 advantage of the added granularity in the entire domain name that is
482 provided, they might unilaterally decide to use only some rightmost
483 part of the identifier. The signer cannot know what portion will be
484 used. That ambiguity would move the use of DKIM back to the realm of
485 heuristics, rather than the deterministic processing that is its
488 Hence, the challenge is to determine a useful scheme for labeling
489 different traffic streams. The most obvious choices are among
490 different types of content and/or different types of authors.
491 Although stability is essential, it is likely that the choices will
492 change, over time, so the scheme needs to be flexible.
506Hansen, et al. Informational [Page 9]
508RFC 5863 DKIM Development/Deployment/Operations May 2010
511 For those originating message content, the most likely choice of
512 subdomain naming scheme will by based upon type of content, which can
513 use content-oriented labels or service-oriented labels. For example:
515 transaction.example.com
516 newsletter.example.com
517 bugreport.example.com
520 marketing.example.com
522 where the choices are best dictated by whether they provide the
523 Identity Assessor with the ability to discriminate usefully among
524 streams of mail that demonstrate significantly different degrees of
525 recipient acceptance or safety. Again, the danger in providing too
526 fine a granularity is that related message streams that are labeled
527 separately will not benefit from an aggregate reputation.
529 For those operating messaging services on behalf of a variety of
530 customers, an obvious scheme to use has a different subdomain label
531 for each customer. For example:
534 moviestudio.example.net
537 However, it can also be appropriate to label by the class of service
538 or class of customer, such as:
542 certified.example.net
544 Prior to using domain names for distinguishing among sources of data,
545 IP Addresses have been the basis for distinction. Service operators
546 typically have done this by dedicating specific outbound IP Addresses
547 to specific mail streams -- typically to specific customers. For
548 example, a university might want to distinguish mail from the
549 administration, versus mail from the student dorms. In order to make
550 the adoption of a DKIM-based service easier, it can be reasonable to
551 translate the same partitioning of traffic, using domain names in
552 place of the different IP Addresses.
5542.4. Recipient-Based Assessments
556 DKIM gives the recipient site's Identity Assessor a verifiable
557 identifier to use for analysis. Although the mechanism does not make
558 claims that the signer is a Good Actor or a Bad Actor, it does make
562Hansen, et al. Informational [Page 10]
564RFC 5863 DKIM Development/Deployment/Operations May 2010
567 it possible to know that use of the identifier is valid. This is in
568 marked contrast with schemes that do not have authentication.
569 Without verification, it is not possible to know whether the
570 identifier -- whether taken from the RFC5322.From field, the
571 RFC5321.MailFrom command, or the like -- is being used by an
572 authorized agent. DKIM solves this problem. Hence, with DKIM, the
573 Assessor can know that two messages with the same DKIM d= identifier
574 are, in fact, signed by the same person or organization. This
575 permits a far more stable and accurate assessment of mail traffic
576 using that identifier.
578 DKIM is distinctive, in that it provides an identifier that is not
579 necessarily related to any other identifier in the message. Hence,
580 the signer might be the author's ADMD, one of the operators along the
581 transit path, or a reputation service being used by one of those
582 handling services. In fact, a message can have multiple signatures,
583 possibly by any number of these actors.
585 As discussed above, the choice of identifiers needs to be based on
586 differences that the signer thinks will be useful for the recipient
587 Assessor. Over time, industry practices establish norms for these
590 Absent such norms, it is best for signers to distinguish among
591 streams that have significant differences, while consuming the
592 smallest number of identifiers possible. This will limit the
593 burden on recipient Assessors.
595 A common view about a DKIM signature is that it carries a degree of
596 assurance about some or all of the message contents, and in
597 particular, that the RFC5322.From field is likely to be valid. In
598 fact, DKIM makes assurances only about the integrity of the data and
599 not about its validity. Still, presumptions of the RFC5322.From
600 field validity remain a concern. Hence, a signer using a domain name
601 that is unrelated to the domain name in the RFC5322.From field can
602 reasonably expect that the disparity will warrant some curiosity, at
603 least until signing by independent operators has produced some
604 established practice among recipient Assessors.
606 With the identifier(s) supplied by DKIM, the Assessor can consult an
607 independent assessment service about the entity associated with the
608 identifier(s). Another possibility is that the Assessor can develop
609 its own reputation rating for the identifier(s). That is, over time,
610 the Assessor can observe the stream of messages associated with the
611 identifier(s) developing a reaction to associated content. For
612 example, if there is a high percentage of user complaints regarding
618Hansen, et al. Informational [Page 11]
620RFC 5863 DKIM Development/Deployment/Operations May 2010
623 signed mail with a d= value of "widgetco.example.net", the Assessor
624 might include that fact in the vector of data it provides to the
625 Handling Filter. This is also discussed briefly in Section 5.4.
629 The assessment of the signing identifier is given to a Handling
630 Filter that is defined by local policies, according to a potentially
631 wide range of different factors and weightings. This section
632 discusses some of the kinds of choices and weightings that are
633 plausible and the differential actions that might be performed.
634 Because authenticated domain names represent a collaborative sequence
635 between signer and Assessor, actions can sometimes reasonably include
636 contacting the signer.
638 The discussion focuses on variations in Organizational Trust versus
639 Message Stream Risk, that is, the degree of positive assessment of a
640 DKIM-signing organization, and the potential danger present in the
641 message stream signed by that organization. While it might seem that
642 higher trust automatically means lower risk, the experience with
643 real-world operations provides examples of every combination of the
644 two factors, as shown in Figure 2. For each axis, only three levels
645 of granularity are listed, in order to keep discussion manageable.
646 In real-world filtering engines, finer-grained distinctions are
647 typically needed, and there typically are more axes. For example,
648 there are different types of risk, so that an engine might
649 distinguish between spam risk versus virus risk and take different
650 actions based on which type of problematic content is present. For
651 spam, the potential damage from a false negative is small, whereas
652 the damage from a false positive is high. For a virus, the potential
653 danger from a false negative is extremely high, while the likelihood
654 of a false positive when using modern detection tools is extremely
655 low. However, for the discussion here, "risk" is taken as a single
658 The DKIM d= identifier is independent of any other identifier in a
659 message and can be a subdomain of the name owned by the signer. This
660 permits the use of fine-grained and stable distinctions between
661 different types of message streams, such as between transactional
662 messages and marketing messages from the same organization. Hence,
663 the use of DKIM might permit a richer filtering model than has
664 typically been possible for mail-receiving engines.
666 Note that the realities of today's public Internet Mail environment
667 necessitate having a baseline handling model that is quite
668 suspicious. Hence, "strong" filtering rules really are the starting
669 point, as indicated for the UNKNOWN cell.
674Hansen, et al. Informational [Page 12]
676RFC 5863 DKIM Development/Deployment/Operations May 2010
679 The table indicates differential handling for each combination, such
680 as how aggressive or broad-based the filtering could be.
681 Aggressiveness affects the types of incorrect assessments that are
682 likely. So, the table distinguishes various characteristics,
683 including: 1) whether an organization is unknown, known to be good
684 actors, or known to be bad actors; and 2) the assessment of messages.
685 It includes advice about the degree of filtering that might be done,
686 and other message disposition. Perhaps unexpectedly, it also lists a
687 case in which the receiving site might wish to deliver problematic
688 mail, rather than redirecting or deleting it. The site might also
689 wish to contact the signing organization and seek resolution of the
692 +-------------+-----------------------------------------------+
693 | S T R E A M * O R G A N I Z A T I O N A L T R U S T |
694 | R I S K * Low Medium High |
695 | +***************+***************+***************+
696 | Low * BENIGN: | DILIGENT: | PRISTINE |
697 | * Moderate | Mild | Accept |
698 | * filter | filter | |
699 | +---------------+---------------+---------------+
700 | Medium * UNKNOWN: | TYPICAL: | PROTECTED: |
701 | * Strong | Targeted | Accept & |
702 | * filter | filter | Contact |
703 | +---------------+---------------+---------------+
704 | High * MALICIOUS: | NEGLIGENT: | COMPROMISED: |
705 | * Block & | Block | Block & |
706 | * Counter | | Contact |
707 +-------------+---------------+---------------+---------------+
709 Figure 2: Trust versus Risk Handling Tradeoffs Example
715 Stream Risk: This is a measure of the recent history of a message
716 stream and the severity of problems it has presented.
718 Organizational Trust: This combines longer-term history about
719 possible stream problems from that organization, and its
720 responsiveness to problem handling.
722 CELLS (indicating reasonable responses)
724 Labels for the cells are meant as a general assessment of an
725 organization producing that type of mail stream under that
730Hansen, et al. Informational [Page 13]
732RFC 5863 DKIM Development/Deployment/Operations May 2010
735 Benign: There is some history of sending good messages, with very
736 few harmful messages having been received. This stream
737 warrants filtering that does not search for problems very
738 aggressively, in order to reduce the likelihood of false
741 Diligent: The stream has had a limited degree of problems and the
742 organization is consistently successful at controlling their
743 abuse issues and in a timely manner.
745 Pristine: There is a history of a clean message stream with no
746 problems, from an organization with an excellent reputation.
747 So, the filter primarily needs to ensure that messages are
748 delivered; catching stray problem messages is a lesser concern.
749 In other words, the paramount concern, here, is false
754 Unknown: There is no history with the organization. Apply an
755 aggressive level of "naive" filtering, given the nature of the
756 public email environment.
758 Typical: The stream suffers significant abuse issues and the
759 organization has demonstrated a record of having difficulties
760 resolving them in a timely manner, in spite of legitimate
761 efforts. Unfortunately, this is the typical case for service
762 providers with an easy and open subscription policy.
764 Protected: An organization with a good history and/or providing
765 an important message stream for the receiving site is subject
766 to a local policy that messages are not allowed to be blocked,
767 but the stream is producing a problematic stream. The receiver
768 delivers messages, but works quickly with the organization to
773 Malicious: A persistently problematic message stream is coming
774 from an organization that appears to contribute to the problem.
775 The stream will be blocked, but the organization's role is
776 sufficiently troubling to warrant following up with others in
777 the anti-abuse or legal communities, to constrain or end their
786Hansen, et al. Informational [Page 14]
788RFC 5863 DKIM Development/Deployment/Operations May 2010
791 Negligent: A persistently problematic message stream is coming
792 from an organization that does not appear to be contributing to
793 the problem, but also does not appear to be working to
794 eliminate it. At the least, the stream needs to be blocked.
796 Compromised: An organization with a good history has a stream
797 that changes and becomes too problematic to be delivered. The
798 receiver blocks the stream and works quickly with the
799 organization to resolve the matter.
8013. DKIM Key Generation, Storage, and Management
803 By itself, verification of a digital signature only allows the
804 verifier to conclude with a very high degree of certainty that the
805 signature was created by a party with access to the corresponding
806 private signing key. It follows that a verifier requires means to
807 (1) obtain the public key for the purpose of verification and (2)
808 infer useful attributes of the key holder.
810 In a traditional Public Key Infrastructure (PKI), the functions of
811 key distribution and key accreditation are separated. In DKIM
812 [RFC4871], these functions are both performed through the DNS.
814 In either case, the ability to infer semantics from a digital
815 signature depends on the assumption that the corresponding private
816 key is only accessible to a party with a particular set of
817 attributes. In a traditional PKI, a Trusted Third Party (TTP)
818 vouches that the key holder has been validated with respect to a
819 specified set of attributes. The range of attributes that can be
820 attested in such a scheme is thus limited only to the type of
821 attributes that a TTP can establish effective processes for
822 validating. In DKIM, TTPs are not employed and the functions of key
823 distribution and accreditation are combined.
825 Consequently, there are only two types of inference that a signer can
826 make from a key published in a DKIM key record:
828 1. That a party with the ability to control DNS records within a DNS
829 zone intends to claim responsibility for messages signed using
830 the corresponding private signature key.
832 2. That use of a specific key is restricted to the particular subset
833 of messages identified by the selector.
835 The ability to draw any useful conclusion from verification of a
836 digital signature relies on the assumption that the corresponding
837 private key is only accessible to a party with a particular set of
842Hansen, et al. Informational [Page 15]
844RFC 5863 DKIM Development/Deployment/Operations May 2010
847 attributes. In the case of DKIM, this means that the party that
848 created the corresponding DKIM key record in the specific zone
849 intended to claim responsibility for the signed message.
851 Ideally, we would like to draw a stronger conclusion, that if we
852 obtain a DKIM key record from the DNS zone example.com, that the
853 legitimate holder of the DNS zone example.com claims responsibility
854 for the signed message. In order for this conclusion to be drawn, it
855 is necessary for the verifier to assume that the operational security
856 of the DNS zone and corresponding private key are adequate.
8583.1. Private Key Management: Deployment and Ongoing Operations
860 Access to signing keys needs to be carefully managed to prevent use
861 by unauthorized parties and to minimize the consequences if a
862 compromise were to occur.
864 While a DKIM signing key is used to sign messages on behalf of many
865 mail users, the signing key itself needs to be under direct control
866 of as few key holders as possible. If a key holder were to leave the
867 organization, all signing keys held by that key holder need to be
868 withdrawn from service and, if appropriate, replaced.
870 If key management hardware support is available, it needs to be used.
871 If keys are stored in software, appropriate file control protections
872 need to be employed, and any location in which the private key is
873 stored in plaintext form needs to be excluded from regular backup
874 processes and is best not accessible through any form of network
875 including private local area networks. Auditing software needs to be
876 used periodically to verify that the permissions on the private key
879 Wherever possible, a signature key needs to exist in exactly one
880 location and be erased when no longer used. Ideally, a signature key
881 pair needs to be generated as close to the signing point as possible,
882 and only the public key component transferred to another party. If
883 this is not possible, the private key needs to be transported in an
884 encrypted format that protects the confidentiality of the signing
885 key. A shared directory on a local file system does not provide
886 adequate security for distribution of signing keys in plaintext form.
888 Key escrow schemes are not necessary and are best not used. In the
889 unlikely event of a signing key becoming lost, a new signature key
890 pair can be generated as easily as recovery from a key escrow scheme.
898Hansen, et al. Informational [Page 16]
900RFC 5863 DKIM Development/Deployment/Operations May 2010
903 To enable accountability and auditing:
905 o Responsibility for the security of a signing key needs to
906 ultimately vest in a single named individual.
908 o Where multiple parties are authorized to sign messages, each
909 signer needs to use a different key to enable accountability and
912 Best practices for management of cryptographic keying material
913 require keying material to be refreshed at regular intervals,
914 particularly where key management is achieved through software.
915 While this practice is highly desirable, it is of considerably less
916 importance than the requirement to maintain the secrecy of the
917 corresponding private key. An operational practice in which the
918 private key is stored in tamper-proof hardware and changed once a
919 year is considerably more desirable than one in which the signature
920 key is changed on an hourly basis but maintained in software.
9223.2. Storing Public Keys: DNS Server Software Considerations
924 In order to use DKIM, a DNS domain holder requires (1) the ability to
925 create the necessary DKIM DNS records and (2) sufficient operational
926 security controls to prevent insertion of spurious DNS records by an
929 DNS record management is often operated by an administrative staff
930 that is different from those who operate an organization's email
931 service. In order to ensure that DKIM DNS records are accurate, this
932 imposes a requirement for careful coordination between the two
933 operations groups. If the best practices for private key management
934 described above are observed, such deployment is not a one-time
935 event; DNS DKIM selectors will be changed over time as signing keys
936 are terminated and replaced.
938 At a minimum, a DNS server that handles queries for DKIM key records
939 needs to allow the server administrators to add free-form TXT
940 records. It would be better if the DKIM records could be entered
941 using a structured form, supporting the DKIM-specific fields.
943 Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a
944 configuration that provides protection against record insertion
945 attacks and zone enumeration. In the case that NextSECure version 3
946 (NSEC3) [RFC5155] records are employed to prevent insertion attack,
947 the OPT-OUT flag needs to be clear. (See [RFC5155] section 6 for
954Hansen, et al. Informational [Page 17]
956RFC 5863 DKIM Development/Deployment/Operations May 2010
9593.2.1. Assignment of Selectors
961 Selectors are assigned according to the administrative needs of the
962 signing domain, such as for rolling over to a new key or for the
963 delegation of the right to authenticate a portion of the namespace to
964 a TTP. Examples include:
966 jun2005.eng._domainkey.example.com
968 widget.promotion._domainkey.example.com
970 It is intended that assessments of DKIM identities be based on the
971 domain name, and not include the selector. While past practice of a
972 signer can permit a verifier to infer additional properties of
973 particular messages from the structure DKIM key selector, unannounced
974 administrative changes such as a change of signing software can cause
975 such heuristics to fail at any time.
9773.3. Per-User Signing Key Management Issues
979 While a signer can establish business rules, such as the issue of
980 individual signature keys for each end-user, DKIM makes no provision
981 for communicating these to other parties. Out-of-band distribution
982 of such business rules is outside the scope of DKIM. Consequently,
983 there is no means by which external parties can make use of such keys
984 to attribute messages with any greater granularity than a DNS domain.
986 If per-user signing keys are assigned for internal purposes (e.g.,
987 authenticating messages sent to an MTA (Mail Transfer Agent) for
988 distribution), the following issues need to be considered before
989 using such signatures as an alternative to traditional edge signing
992 External verifiers will be unable to make use of the additional
993 signature granularity without access to additional information
994 passed out of band with respect to [RFC4871].
996 If the number of user keys is large, the efficiency of local
997 caching of key records by verifiers will be lower.
999 A large number of end users is be less likely to do an adequate
1000 job of managing private key data securely on their personal
1001 computers than is an administrator running an edge MTA.
1010Hansen, et al. Informational [Page 18]
1012RFC 5863 DKIM Development/Deployment/Operations May 2010
10153.4. Third-Party Signer Key Management and Selector Administration
1017 A DKIM key record only asserts that the holder of the corresponding
1018 domain name makes a claim of responsibility for messages signed under
1019 the corresponding key. In some applications, such as bulk mail
1020 delivery, it is desirable to delegate use of the key. That is, to
1021 allow a third party to sign on behalf of the domain holder. The
1022 trust relationship is still established between the domain holder and
1023 the verifier, but the private signature key is held by a third party.
1025 Signature keys used by a third-party signer need to be kept entirely
1026 separate from those used by the domain holder and other third-party
1027 signers. To limit potential exposure of the private key, the
1028 signature key pair needs to be generated by the third-party signer
1029 and the public component of the key transmitted to the domain holder,
1030 rather than have the domain holder generate the key pair and transmit
1031 the private component to the third-party signer.
1033 Domain holders needs to adopt a least-privilege approach and grant
1034 third-party signers the minimum access necessary to perform the
1035 desired function. Limiting the access granted to third-party signers
1036 serves to protect the interests of both parties. The domain holder
1037 minimizes its security risk and the TTP signer avoids unnecessary
1040 In the most restrictive case, domain holders maintain full control
1041 over the creation of key records. They can employ appropriate key
1042 record restrictions to enforce limits on the messages for which the
1043 third-party signer is able to sign. If such restrictions are
1044 impractical, the domain holder needs to delegate a DNS subzone for
1045 publishing key records to the third-party signer. It is best that
1046 the domain holder NOT allow a third-party signer unrestricted access
1047 to its DNS service for the purpose of publishing key records.
10493.5. Key Pair / Selector Life Cycle Management
1051 Deployments need to establish, document, and observe processes for
1052 managing the entire life cycle of an asymmetric key pair.
10543.5.1. Example Key Deployment Process
1056 When it is determined that a new key pair is required:
1058 1. A Key Pair is generated by the signing device.
1060 2. A proposed key selector record is generated and transmitted to
1061 the DNS administration infrastructure.
1066Hansen, et al. Informational [Page 19]
1068RFC 5863 DKIM Development/Deployment/Operations May 2010
1071 3. The DNS administration infrastructure verifies the authenticity
1072 of the key selector registration request. If accepted:
1074 1. A key selector is assigned.
1076 2. The corresponding key record is published in the DNS.
1078 3. Wait for DNS updates to propagate (if necessary).
1080 4. Report assigned key selector to signing device.
1082 4. The signer verifies correct registration of the key record.
1084 5. The signer begins generating signatures using the new key pair.
1086 6. The signer terminates any private keys that are no longer
1087 required due to issue of replacement.
10893.5.2. Example Key Termination Process
1091 When it is determined that a private signature key is no longer
1094 1. The signer stops using the private key for signature operations.
1096 2. The signer deletes all records of the private key, including in-
1097 memory copies at the signing device.
1099 3. The signer notifies the DNS administration infrastructure that
1100 the signing key is withdrawn from service and that the
1101 corresponding key records can be withdrawn from service at a
1102 specified future date.
1104 4. The DNS administration infrastructure verifies the authenticity
1105 of the key selector termination request. If accepted,
1107 1. The key selector is scheduled for deletion at a future time
1108 determined by site policy.
1110 2. Wait for deletion time to arrive.
1112 3. The signer either publishes a revocation key selector with an
1113 empty public-key data (p=) field, or deletes the key selector
1116 5. As far as the verifier is concerned, there is no functional
1117 difference between verifying against a key selector with an empty
1118 p= field, and verifying against a missing key selector: both
1122Hansen, et al. Informational [Page 20]
1124RFC 5863 DKIM Development/Deployment/Operations May 2010
1127 result in a failed signature and the signature needs to be
1128 treated as if it had not been there. However, there is a minor
1129 semantic difference: with the empty p= field, the signer is
1130 explicitly stating that the key has been revoked. The empty p=
1131 record provides a gravestone for an old selector, making it less
1132 likely that the selector might be accidentally reused with a
1133 different public key.
1137 Creating messages that have one or more DKIM signatures requires
1138 support in only two outbound email service components:
1140 o A DNS Administrative interface that can create and maintain the
1141 relevant DNS names -- including names with underscores -- and
1142 resource records (RR).
1144 o A trusted module, called the signing module, which is within the
1145 organization's outbound email handling service and which creates
1146 and adds the DKIM-Signature: header field(s) to the message.
1148 If the module creates more than one signature, there needs to be the
1149 appropriate means of telling it which one(s) to use. If a large
1150 number of names are used for signing, it will help to have the
1151 administrative tool support a batch-processing mode.
1155 A receiver attempting to verify a DKIM signature obtains the public
1156 key that is associated with the signature for that message. The
1157 DKIM-Signature: header in the message contains the d= tag with the
1158 basic domain name doing the signing and serving as output to the
1159 Identity Assessor and the s= tag with the selector that is added to
1160 the name, for finding the specific public key. Hence, the relevant
1161 <selector>._domainkey.<domain-name> DNS record needs to contain a
1162 DKIM-related RR that provides the public key information.
1164 The administrator of the zone containing the relevant domain name
1165 adds this information. Initial DKIM DNS information is contained
1166 within TXT RRs. DNS administrative software varies considerably in
1167 its abilities to support DKIM names, such as with underscores, and to
1168 add new types of DNS information.
1172 The module doing signing can be placed anywhere within an
1173 organization's trusted Administrative Management Domain (ADMD);
1174 obvious choices include department-level posting agents, as well as
1178Hansen, et al. Informational [Page 21]
1180RFC 5863 DKIM Development/Deployment/Operations May 2010
1183 outbound boundary MTAs to the open Internet. However, any other
1184 module, including the author's MUA (Mail User Agent), is potentially
1185 acceptable, as long as the signature survives any remaining handling
1186 within the ADMD. Hence, the choice among the modules depends upon
1187 software development, administrative overhead, security exposures,
1188 and transit-handling tradeoffs. One perspective that helps to
1189 resolve this choice is the difference between the increased
1190 flexibility, from placement at (or close to) the MUA, versus the
1191 streamlined administration and operation that is more easily obtained
1192 by implementing the mechanism "deeper" into the organization's email
1193 infrastructure, such as at its boundary MTA.
1195 Note the discussion in Section 2.2 concerning the use of the i= tag.
1197 The signing module uses the appropriate private key to create one or
1198 more signatures. (See Section 6.5 for a discussion of multiple
1199 signatures.) The means by which the signing module obtains the
1200 private key(s) is not specified by DKIM. Given that DKIM is intended
1201 for use during email transit, rather than for long-term storage, it
1202 is expected that keys will be changed regularly. For administrative
1203 convenience, it is best not to hard-code key information into
12064.3. Signing Policies and Practices
1208 Every organization (ADMD) will have its own policies and practices
1209 for deciding when to sign messages (message stream) and with what
1210 domain name, selector, and key. Examples of particular message
1211 streams include all mail sent from the ADMD versus mail from
1212 particular types of user accounts versus mail having particular types
1213 of content. Given this variability, and the likelihood that signing
1214 practices will change over time, it will be useful to have these
1215 decisions represented through run-time configuration information,
1216 rather than being hard-coded into the signing software.
1218 As noted in Section 2.3, the choice of signing name granularity
1219 requires balancing administrative convenience and utility for
1220 recipients. Too much granularity is higher administrative overhead
1221 and might well attempt to impose more differential analysis on the
1222 recipient than they wish to support. In such cases, they are likely
1223 to use only a super-name -- right-hand substring -- of the signing
1224 name. When this occurs, the signer will not know what portion is
1225 being used; this then moves DKIM back to the non-deterministic world
1226 of heuristics, rather than the mechanistic world of signer/recipient
1227 collaboration that DKIM seeks.
1234Hansen, et al. Informational [Page 22]
1236RFC 5863 DKIM Development/Deployment/Operations May 2010
1241 A message recipient can verify a DKIM signature to determine if a
1242 claim of responsibility has been made for the message by a trusted
1245 Access control requires two components: authentication and
1246 authorization. By design, verification of a DKIM signature only
1247 provides the authentication component of an access control decision
1248 and needs to be combined with additional sources of information such
1249 as reputation data to arrive at an access control decision.
12515.1. Intended Scope of Use
1253 DKIM requires that a message with a signature that is found to be
1254 invalid is to be treated as if the message had not been signed at
1257 If a DKIM signature fails to verify, it is entirely possible that the
1258 message is valid and that either there is a configuration error in
1259 the signer's system (e.g., a missing key record) or that the message
1260 was inadvertently modified in transit. It is thus undesirable for
1261 mail infrastructure to treat messages with invalid signatures less
1262 favorably than those with no signatures whatsoever. Contrariwise,
1263 creation of an invalid signature requires a trivial amount of effort
1264 on the part of an attacker. If messages with invalid signatures were
1265 to be treated preferentially to messages with no signatures
1266 whatsoever, attackers will simply add invalid signature blocks to
1267 gain the preferential treatment. It follows that messages with
1268 invalid signatures need to be treated no better and no worse than
1269 those with no signature at all.
1273 As with any other digital signature scheme, verifiers need to
1274 consider only the part of the message that is inside the scope of the
1275 message as being authenticated by the signature.
1277 For example, if the l= option is employed to specify a content length
1278 for the scope of the signature, only the part of the message that is
1279 within the scope of the content signature would be considered
1290Hansen, et al. Informational [Page 23]
1292RFC 5863 DKIM Development/Deployment/Operations May 2010
12955.3. Design Scope of Use
1297 Public key cryptography provides an exceptionally high degree of
1298 assurance, bordering on absolute certainty, that the party that
1299 created a valid digital signature had access to the private key
1300 corresponding to the public key indicated in the signature.
1302 In order to make useful conclusions from the verification of a valid
1303 digital signature, the verifier is obliged to make assumptions that
1304 fall far short of absolute certainty. Consequently, mere validation
1305 of a DKIM signature does not represent proof positive that a valid
1306 claim of responsibility was made for it by the indicated party, that
1307 the message is authentic, or that the message is not abusive. In
1310 o The legitimate private key holder might have lost control of its
1313 o The legitimate domain holder might have lost control of the DNS
1314 server for the zone from which the key record was retrieved.
1316 o The key record might not have been delivered from the legitimate
1317 DNS server for the zone from which the key record was retrieved.
1319 o Ownership of the DNS zone might have changed.
1321 In practice, these limitations have little or no impact on the field
1322 of use for which DKIM is designed, but they can have a bearing if use
1323 is made of the DKIM message signature format or key retrieval
1324 mechanism in other specifications.
1326 In particular, the DKIM key retrieval mechanism is designed for ease
1327 of use and deployment rather than to provide a high assurance Public
1328 Key Infrastructure suitable for purposes that require robust non-
1329 repudiation such as establishing legally binding contracts.
1330 Developers seeking to extend DKIM beyond its design application need
1331 to consider replacing or supplementing the DNS key retrieval
1332 mechanism with one that is designed to meet the intended purposes.
13345.4. Inbound Mail Filtering
1336 DKIM is frequently employed in a mail filtering strategy to avoid
1337 performing content analysis on email originating from trusted
1338 sources. Messages that carry a valid DKIM signature from a trusted
1339 source can be whitelisted, avoiding the need to perform computation
1340 and hence energy-intensive content analysis to determine the
1341 disposition of the message.
1346Hansen, et al. Informational [Page 24]
1348RFC 5863 DKIM Development/Deployment/Operations May 2010
1351 Mail sources can be determined to be trusted by means of previously
1352 observed behavior and/or reference to external reputation or
1353 accreditation services. The precise means by which this is
1354 accomplished is outside the scope of DKIM.
13565.4.1. Non-Verifying Adaptive Spam Filtering Systems
1358 Adaptive (or learning) spam filtering mechanisms that are not capable
1359 of verifying DKIM signatures need to, at minimum, be configured to
1360 ignore DKIM header data entirely.
13625.5. Messages Sent through Mailing Lists and Other Intermediaries
1364 Intermediaries, such as mailing lists, pose a particular challenge
1365 for DKIM implementations, as the message processing steps performed
1366 by the intermediary can cause the message content to change in ways
1367 that prevent the signature passing verification.
1369 Such intermediaries are strongly encouraged to deploy DKIM signing so
1370 that a verifiable claim of responsibility remains available to
1371 parties attempting to verify the modified message.
13735.6. Generation, Transmission, and Use of Results Headers
1375 In many deployments, it is desirable to separate signature
1376 verification from the application relying on the verification. A
1377 system can choose to relay information indicating the results of its
1378 message authentication efforts using various means; adding a "results
1379 header" to the message is one such mechanism [RFC5451]. For example,
1380 consider the cases where:
1382 o The application relying on DKIM signature verification is not
1383 capable of performing the verification.
1385 o The message can be modified after the signature verification is
1388 o The signature key cannot be available by the time that the message
1391 In such cases, it is important that the communication link between
1392 the signature verifier and the relying application be sufficiently
1393 secure to prevent insertion of a message that carries a bogus results
1396 An intermediary that generates results headers need to ensure that
1397 relying applications are able to distinguish valid results headers
1398 issued by the intermediary from those introduced by an attacker. For
1402Hansen, et al. Informational [Page 25]
1404RFC 5863 DKIM Development/Deployment/Operations May 2010
1407 example, this can be accomplished by signing the results header. At
1408 a minimum, results headers on incoming messages need to be removed if
1409 they purport to have been issued by the intermediary but cannot be
1410 verified as authentic.
1412 Further discussion on trusting the results as relayed from a verifier
1413 to something downstream can be found in [RFC5451].
14156. Taxonomy of Signatures
1417 As described in Section 2.1, a DKIM signature tells the signature
1418 verifier that the owner of a particular domain name accepts some
1419 responsibility for the message. It does not, in and of itself,
1420 provide any information about the trustworthiness or behavior of that
1421 identity. What it does provide is a verified identity to which such
1422 behavioral information can be associated, so that those who collect
1423 and use such information can be assured that it truly pertains to the
1424 identity in question.
1426 This section lays out a taxonomy of some of the different identities,
1427 or combinations of identities, that might usefully be represented by
14306.1. Single Domain Signature
1432 Perhaps the simplest case is when an organization signs its own
1433 outbound email using its own domain in the SDID [RFC5672] of the
1434 signature. For example, Company A would sign the outbound mail from
1435 its employees with d=companyA.example.
1437 In the most straightforward configuration, the addresses in the
1438 RFC5322.From field would also be in the companyA.example domain, but
1439 that direct correlation is not required.
1441 A special case of the single domain signature is an author signature
1442 as defined by the Author Domain Signing Practices specification
1443 [RFC5617]. Author signatures are signatures from an author's
1444 organization that have an SDID value that matches that of an
1445 RFC5322.From address of the signed message.
1447 Although an author signature might, in some cases, be proof against
1448 spoofing the domain name of the RFC5322.From address, it is important
1449 to note that the DKIM and ADSP validation apply only to the exact
1450 address string and not to look-alike addresses or to the human-
1451 friendly "display-name" or names and addresses used within the body
1452 of the message. That is, it only protects against the misuse of a
1453 precise address string within the RFC5322.From field and nothing
1454 else. For example, a message from bob@domain.example with a valid
1458Hansen, et al. Informational [Page 26]
1460RFC 5863 DKIM Development/Deployment/Operations May 2010
1463 signature where d=d0main.example would fail an ADSP check because the
1464 signature domain, however similar, is distinct; however, a message
1465 from bob@d0main.example with a valid signature where d=d0main.example
1466 would pass an ADSP check, even though to a human it might be obvious
1467 that d0main.example is likely a malicious attempt to spoof the domain
1468 domain.example. This example highlights that ADSP, like DKIM, is
1469 only able to validate a signing identifier: it still requires some
1470 external process to attach a meaningful reputation to that
14736.2. Parent Domain Signature
1475 Another approach that might be taken by an organization with multiple
1476 active subdomains is to apply the same (single) signature domain to
1477 mail from all subdomains. In this case, the signature chosen would
1478 usually be the signature of a parent domain common to all subdomains.
1479 For example, mail from marketing.domain.example,
1480 sales.domain.example, and engineering.domain.example might all use a
1481 signature where d=domain.example.
1483 This approach has the virtue of simplicity, but it is important to
1484 consider the implications of such a choice. As discussed in
1485 Section 2.3, if the type of mail sent from the different subdomains
1486 is significantly different or if there is reason to believe that the
1487 reputation of the subdomains would differ, then it can be a good idea
1488 to acknowledge this and provide distinct signatures for each of the
1489 subdomains (d=marketing.domain.example, sales.domain.example, etc.).
1490 However, if the mail and reputations are likely to be similar, then
1491 the simpler approach of using a single common parent domain in the
1492 signature can work well.
1494 Another approach to distinguishing the streams using a single DKIM
1495 key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM
1496 signature to differentiate the mail streams. For example, marketing
1497 email would be signed with i=@marketing.domain.example and
1500 It's important to remember, however, that under core DKIM semantics,
1501 the AUID is opaque to receivers. That means that it will only be an
1502 effective differentiator if there is an out-of-band agreement about
15056.3. Third-Party Signature
1507 A signature whose domain does not match the domain of the
1508 RFC5322.From address is sometimes referred to as a third-party
1509 signature. In certain cases, even the parent domain signature
1514Hansen, et al. Informational [Page 27]
1516RFC 5863 DKIM Development/Deployment/Operations May 2010
1519 described above would be considered a third-party signature because
1520 it would not be an exact match for the domain in the RFC5322.From
1523 Although there is often heated debate about the value of third party
1524 signatures, it is important to note that the DKIM specification
1525 attaches no particular significance to the identity in a DKIM
1526 signature ([RFC4871], [RFC5672]). The identity specified within the
1527 signature is the identity that is taking responsibility for the
1528 message, and it is only the interpretation of a given receiver that
1529 gives one identity more or less significance than another. In
1530 particular, most independent reputation services assign trust based
1531 on the specific identifier string, not its "role": in general they
1532 make no distinction between, for example, an author signature and a
1533 third-party signature.
1535 For some, a signature unrelated to the author domain (the domain in
1536 the RFC5322.From address) is less valuable because there is an
1537 assumption that the presence of an author signature guarantees that
1538 the use of the address in the RFC5322.From header is authorized.
1540 For others, that relevance is tied strictly to the recorded
1541 behavioral data assigned to the identity in question, i.e., its trust
1542 assessment or reputation. The reasoning here is that an identity
1543 with a good reputation is unlikely to maintain that good reputation
1544 if it is in the habit of vouching for messages that are unwanted or
1545 abusive; in fact, doing so will rapidly degrade its reputation so
1546 that future messages will no longer benefit from it. It is therefore
1547 low risk to facilitate the delivery of messages that contain a valid
1548 signature of a domain with a strong positive reputation, independent
1549 of whether or not that domain is associated with the address in the
1550 RFC5322.From header field of the message.
1552 Third-party signatures encompass a wide range of identities. Some of
1553 the more common are:
1555 Service Provider: In cases where email is outsourced to an Email
1556 Service Provider (ESP), Internet Service Provider (ISP), or other
1557 type of service provider, that service provider can choose to
1558 DKIM-sign outbound mail with either its own identifier -- relying
1559 on its own, aggregate reputation -- or with a subdomain of the
1560 provider that is unique to the message author but still part of
1561 the provider's aggregate reputation. Such service providers can
1562 also encompass delegated business functions such as benefit
1563 management, although these will more often be treated as trusted
1564 third-party senders (see below).
1570Hansen, et al. Informational [Page 28]
1572RFC 5863 DKIM Development/Deployment/Operations May 2010
1575 Parent Domain: As discussed above, organizations choosing to apply a
1576 parent-domain signature to mail originating from subdomains can
1577 have their signatures treated as third party by some verifiers,
1578 depending on whether or not the "t=s" tag is used to constrain the
1579 parent signature to apply only to its own specific domain. The
1580 default is to consider a parent-domain signature valid for its
1583 Reputation Provider: Another possible category of third-party
1584 signature would be the identity of a third-party reputation
1585 provider. Such a signature would indicate to receivers that the
1586 message was being vouched for by that third party.
15886.4. Using Trusted Third-Party Senders
1590 For most of the cases described so far, there has been an assumption
1591 that the signing agent was responsible for creating and maintaining
1592 its own DKIM signing infrastructure, including its own keys, and
1593 signing with its own identity.
1595 A different model arises when an organization uses a trusted third-
1596 party sender for certain key business functions, but still wants that
1597 email to benefit from the organization's own identity and reputation.
1598 In other words, the mail would come out of the trusted third party's
1599 mail servers, but the signature applied would be that of the
1600 controlling organization.
1602 This can be done by having the third party generate a key pair that
1603 is designated uniquely for use by that trusted third party and
1604 publishing the public key in the controlling organization's DNS
1605 domain, thus enabling the third party to sign mail using the
1606 signature of the controlling organization. For example, if Company A
1607 outsources its employee benefits to a third party, it can use a
1608 special key pair that enables the benefits company to sign mail as
1609 "companyA.example". Because the key pair is unique to that trusted
1610 third party, it is easy for Company A to revoke the authorization if
1611 necessary by simply removing the public key from the companyA.example
1614 A more cautious approach would be to create a dedicated subdomain
1615 (e.g., benefits.companyA.example) to segment the outsourced mail
1616 stream, and to publish the public key there; the signature would then
1617 use d=benefits.companyA.example.
1626Hansen, et al. Informational [Page 29]
1628RFC 5863 DKIM Development/Deployment/Operations May 2010
16316.4.1. DNS Delegation
1633 Another possibility for configuring trusted third-party access, as
1634 discussed in Section 3.4, is to have Company A use DNS delegation and
1635 have the designated subdomain managed directly by the trusted third
1636 party. In this case, Company A would create a subdomain
1637 benefits.companya.example, and delegate the DNS management of that
1638 subdomain to the benefits company so it could maintain its own key
1639 records. When revocation becomes necessary, Company A could simply
1640 remove the DNS delegation record.
16426.5. Multiple Signatures
1644 A simple configuration for DKIM-signed mail is to have a single
1645 signature on a given message. This works well for domains that
1646 manage and send all of their own email from single sources, or for
1647 cases where multiple email streams exist but each has its own unique
1648 key pair. It also represents the case in which only one of the
1649 participants in an email sequence is able to sign, no matter whether
1650 it represents the author or one of the operators.
1652 The examples thus far have considered the implications of using
1653 different identities in DKIM signatures, but have used only one such
1654 identity for any given message. In some cases, it can make sense to
1655 have more than one identity claiming responsibility for the same
1658 There are a number of situations where applying more than one DKIM
1659 signature to the same message might make sense. A few examples are:
1661 Companies with multiple subdomain identities: A company that has
1662 multiple subdomains sending distinct categories of mail might
1663 choose to sign with distinct subdomain identities to enable each
1664 subdomain to manage its own identity. However, it might also want
1665 to provide a common identity that cuts across all of the distinct
1666 subdomains. For example, Company A can sign mail for its sales
1667 department with a signature where d=sales.companya.example and a
1668 second signature where d=companya.example
1670 Service Providers: A service provider can, as described above,
1671 choose to sign outbound messages with either its own identity or
1672 an identity unique to each of its clients (possibly delegated).
1673 However, it can also do both: sign each outbound message with its
1674 own identity as well as with the identity of each individual
1675 client. For example, ESP A might sign mail for its client Company
1676 B with its service provider signature d=espa.example, and a second
1677 client-specific signature where d= either companyb.example or
1678 companyb.espa.example. The existence of the service provider
1682Hansen, et al. Informational [Page 30]
1684RFC 5863 DKIM Development/Deployment/Operations May 2010
1687 signature could, for example, help cover a new client while it
1688 establishes its own reputation, or help a very small volume client
1689 who might never reach a volume threshold sufficient to establish
1690 an individual reputation.
1692 Forwarders: Forwarded mail poses a number of challenges to email
1693 authentication. DKIM is relatively robust in the presence of
1694 forwarders as long as the signature is designed to avoid message
1695 parts that are likely to be modified; however, some forwarders do
1696 make modifications that can invalidate a DKIM signature.
1698 Some forwarders such as mailing lists or "forward article to a
1699 friend" services might choose to add their own signatures to
1700 outbound messages to vouch for them having legitimately originated
1701 from the designated service. In this case, the signature would be
1702 added even in the presence of a preexisting signature, and both
1703 signatures would be relevant to the verifier.
1705 Any forwarder that modifies messages in ways that will break
1706 preexisting DKIM signatures needs to sign its forwarded messages.
1708 Reputation Providers: Although third-party reputation providers
1709 today use a variety of protocols to communicate their information
1710 to receivers, it is possible that they, or other organizations
1711 willing to put their "seal of approval" on an email stream, might
1712 choose to use a DKIM signature to do it. In nearly all cases,
1713 this "reputation" signature would be in addition to the author or
1714 originator signature.
1716 One important caveat to the use of multiple signatures is that there
1717 is currently no clear consensus among receivers on how they plan to
1718 handle them. The opinions range from ignoring all but one signature
1719 (and the specification of which of them is verified differs from
1720 receiver to receiver), to verifying all signatures present and
1721 applying a weighted blend of the trust assessments for those
1722 identifiers, to verifying all signatures present and simply using the
1723 identifier that represents the most positive trust assessment. It is
1724 likely that the industry will evolve to accept multiple signatures
1725 using either the second or third of these, but it can take some time
1726 before one approach becomes pervasive.
17287. Example Usage Scenarios
1730 Signatures are created by different types of email actors, based on
1731 different criteria, such as where the actor operates in the sequence
1732 from author to recipient, whether they want different messages to be
1733 evaluated under the same reputation or a different one, and so on.
1738Hansen, et al. Informational [Page 31]
1740RFC 5863 DKIM Development/Deployment/Operations May 2010
1743 This section provides some examples of usage scenarios for DKIM
1744 deployments; the selection is not intended to be exhaustive but to
1745 illustrate a set of key deployment considerations.
17477.1. Author's Organization - Simple
1749 The simplest DKIM configuration is to have some mail from a given
1750 organization (Company A) be signed with the same d= value (e.g.,
1751 d=companya.example). If there is a desire to associate additional
1752 information, the AUID [RFC5672] value can become
1753 uniqueID@companya.example, or @uniqueID.companya.example.
1755 In this scenario, Company A need only generate a single signing key
1756 and publish it under their top-level domain (companya.example); the
1757 signing module would then tailor the AUID value as needed at signing
17607.2. Author's Organization - Differentiated Types of Mail
1762 A slight variation of the one signature case is where Company A signs
1763 some of its mail, but it wants to differentiate among categories of
1764 its outbound mail by using different identifiers. For example, it
1765 might choose to distinguish marketing, billing or transactional, and
1766 individual corporate email into marketing.companya.example,
1767 billing.companya.example, and companya.example, respectively, where
1768 each category is assigned a unique subdomain and unique signing keys.
17707.3. Author Domain Signing Practices
1774 Some domains might decide to sign all of their outgoing mail. If all
1775 of the legitimate mail for a domain is signed, recipients can be more
1776 aggressive in their filtering of mail that uses the domain but does
1777 not have a valid signature from the domain; in such a configuration,
1778 the absence of a signature would be more significant than for the
1779 general case. It might be desirable for such domains to be able to
1780 advertise their intent to other receivers: this is the topic of
1781 Author Domain Signing Practices (ADSP).
1783 Note that ADSP is not for everyone. Sending domains that do not
1784 control all legitimate outbound mail purporting to be from their
1785 domain (i.e., with an RFC5322.From address in their domain) are
1786 likely to experience delivery problems with some percentage of that
1787 mail. Administrators evaluating ADSP for their domains needs to
1788 carefully weigh the risk of phishing attacks against the likelihood
1789 of undelivered mail.
1794Hansen, et al. Informational [Page 32]
1796RFC 5863 DKIM Development/Deployment/Operations May 2010
1799 This section covers some examples of ADSP usage. For the complete
1800 specification, see [RFC5617].
18027.3.2. A Few Definitions
1804 In the ADSP specification, an address in the RFC5322.From header
1805 field of a message is defined as an "Author Address", and an "Author
1806 Domain" is defined as anything to the right of the '@' in an author
1809 An "Author Signature" is thus any valid signature where the value of
1810 the SDID matches an author domain in the message.
1812 It is important to note that unlike the DKIM specification, which
1813 makes no correlation between the signature domain and any message
1814 headers, the ADSP specification applies only to the author domain.
1815 In essence, under ADSP, any non-author signatures are ignored
1816 (treated as if they are not present).
1818 Signers wishing to publish an Author Domain Signing Practices (ADSP)
1819 [RFC5617] record describing their signing practices will thus want to
1820 include an author signature on their outbound mail to avoid ADSP
1821 verification failures.
18237.3.3. Some ADSP Examples
1825 An organization (Company A) can specify its signing practices by
1826 publishing an ADSP record with "dkim=all" or "dkim=discardable". In
1827 order to avoid misdelivery of its mail at receivers that are
1828 validating ADSP, Company A needs to first have done an exhaustive
1829 analysis to determine all sources of outbound mail from its domain
1830 (companyA.example) and ensure that they all have valid author
1831 signatures from that domain.
1833 For example, email with an RFC5322.From address of bob@
1834 companyA.example needs to have an author signature where the SDID
1835 value is "companyA.example" or it will fail an ADSP validation.
1837 Note that once an organization publishes an ADSP record using
1838 dkim=all or dkim=discardable, any email with an RFC5322.From address
1839 that uses the domain where the ADSP record is published that does not
1840 have a valid author signature is at risk of being misdelivered or
1841 discarded. For example, if a message with an RFC5322.From address of
1842 newsletter@companyA.example has a signature with
1843 d=marketing.companyA.example, that message will fail the ADSP check
1844 because the signature would not be considered a valid author
1850Hansen, et al. Informational [Page 33]
1852RFC 5863 DKIM Development/Deployment/Operations May 2010
1855 Because the semantics of an ADSP author signature are more
1856 constrained than the semantics of a "pure" DKIM signature, it is
1857 important to make sure the nuances are well understood before
1858 deploying an ADSP record. The ADSP specification [RFC5617] provides
1859 some fairly extensive lookup examples (in Appendix A) and usage
1860 examples (in Appendix B).
1862 In particular, in order to prevent mail from being negatively
1863 impacted or even discarded at the receiver, it is essential to
1864 perform a thorough survey of outbound mail from a domain before
1865 publishing an ADSP policy of anything stronger than "unknown". This
1866 includes mail that might be sent from external sources that might not
1867 be authorized to use the domain signature, as well as mail that risks
1868 modification in transit that might invalidate an otherwise valid
1869 author signature (e.g., mailing lists, courtesy forwarders, and other
1870 paths that could add or modify headers or modify the message body).
18727.4. Delegated Signing
1874 An organization might choose to outsource certain key services to an
1875 independent company. For example, Company A might outsource its
1876 benefits management, or Organization B might outsource its marketing
1879 If Company A wants to ensure that all of the mail sent on its behalf
1880 through the benefits providers email servers shares the Company A
1881 reputation, as discussed in Section 6.4, it can either publish keys
1882 designated for the use of the benefits provider under
1883 companyA.example (preferably under a designated subdomain of
1884 companyA.example), or it can delegate a subdomain (e.g.,
1885 benefits.companyA.example) to the provider and enable the provider to
1886 generate the keys and manage the DNS for the designated subdomain.
1888 In both of these cases, mail would be physically going out of the
1889 benefit provider's mail servers with a signature of, e.g.,
1890 d=benefits.companya.example. Note that the RFC5322.From address is
1891 not constrained: it could be affiliated with either the benefits
1892 company (e.g., benefits-admin@benefitprovider.example, or
1893 benefits-provider@benefits.companya.example) or the companyA domain.
1895 Note that in both of the above scenarios, as discussed in
1896 Section 3.4, security concerns dictate that the keys be generated by
1897 the organization that plans to do the signing so that there is no
1898 need to transfer the private key. In other words, the benefits
1899 provider would generate keys for both of the above scenarios.
1906Hansen, et al. Informational [Page 34]
1908RFC 5863 DKIM Development/Deployment/Operations May 2010
19117.5. Independent Third-Party Service Providers
1913 Another way to manage the service provider configuration would be to
1914 have the service provider sign the outgoing mail on behalf of its
1915 client, Company A, with its own (provider) identifier. For example,
1916 an Email Service Provider (ESP A) might want to share its own mailing
1917 reputation with its clients, and might sign all outgoing mail from
1918 its clients with its own d= domain (e.g., d=espa.example).
1920 When the ESP wants to distinguish among its clients, it has two
1923 o Share the SDID domain and use the AUID value to distinguish among
1924 the clients, e.g., a signature on behalf of client A would have
1925 d=espa.example and i=@clienta.espa.example (or
1926 i=clienta@espa.example).
1928 o Extend the SDID domain, so there is a unique value (and subdomain)
1929 for each client, e.g., a signature on behalf of client A would
1930 have d=clienta.espa.example.
1932 Note that this scenario and the delegation scenario are not mutually
1933 exclusive. In some cases, it can be desirable to sign the same
1934 message with both the ESP and the ESP client identities.
19367.6. Mail Streams Based on Behavioral Assessment
1938 An ISP (ISP A) might want to assign signatures to outbound mail from
1939 its users according to each user's past sending behavior
1940 (reputation). In other words, the ISP would segment its outbound
1941 traffic according to its own assessment of message quality, to aid
1942 recipients in differentiating among these different streams. Since
1943 the semantics of behavioral assessments are not valid AUID values,
1944 ISP A (ispa.example) can configure subdomains corresponding to the
1945 assessment categories (e.g., good.ispa.example, neutral.ispa.example,
1946 bad.ispa.example), and use these subdomains in the d= value of the
1949 The signing module can also set the AUID value to have a unique user
1950 ID (distinct from the local-part of the user's email address), for
1951 example, user3456@neutral.domain.example. Using a user ID that is
1952 distinct from a given email alias is useful in environments where a
1953 single user might register multiple email aliases.
1955 Note that in this case, the AUID values are only partially stable.
1956 They are stable in the sense that a given i= value will always
1957 represent the same identity, but they are unstable in the sense that
1962Hansen, et al. Informational [Page 35]
1964RFC 5863 DKIM Development/Deployment/Operations May 2010
1967 a given user can migrate among the assessment subdomains depending on
1968 their sending behavior (i.e., the same user might have multiple AUID
1969 values over the lifetime of a single account).
1971 In this scenario, ISP A can generate as many keys as there are
1972 assessment subdomains (SDID values), so that each assessment
1973 subdomain has its own key. The signing module would then choose its
1974 signing key based on the assessment of the user whose mail was being
1975 signed, and if desired, include the user ID in the AUID of the
1976 signature. As discussed earlier, the per-user granularity of the
1977 AUID can be ignored by verifiers; so organizations choosing to use it
1978 ought not rely on its use for receiver side filtering results.
1979 However, some organizations might also find the information useful
1980 for their own purposes in processing bounces or abuse reports.
19827.7. Agent or Mediator Signatures
1984 Another scenario is that of an agent, usually a re-mailer of some
1985 kind, that signs on behalf of the service or organization that it
1986 represents. Some examples of agents might be a mailing list manager,
1987 or the "forward article to a friend" service that many online
1988 publications offer. In most of these cases, the signature is
1989 asserting that the message originated with, or was relayed by, the
1990 service asserting responsibility. In general, if the service is
1991 configured in such a way that its forwarding would break existing
1992 DKIM signatures, it needs to always add its own signature.
19948. Usage Considerations
19968.1. Non-Standard Submission and Delivery Scenarios
1998 The robustness of DKIM's verification mechanism is based on the fact
1999 that only authorized signing modules have access to the designated
2000 private key. This has the side effect that email submission and
2001 delivery scenarios that originate or relay messages from outside the
2002 domain of the authorized signing module will not have access to that
2003 protected private key, and thus will be unable to attach the expected
2004 domain signature to those messages. Such scenarios include mailing
2005 lists, courtesy forwarders, MTAs at hotels, hotspot networks used by
2006 traveling users, and other paths that could add or modify headers, or
2007 modify the message body.
2009 For example, assume Joe works for Company A and has an email address
2010 joe@companya.example. Joe also has an ISP-1 account
2011 joe@isp1.example.com, and he uses ISP-1's multiple address feature to
2012 attach his work email address, joe@companya.example, to email from
2013 his ISP-1 account. When Joe sends email from his ISP-1 account and
2014 uses joe@companya.example as his designated RFC5322.From address,
2018Hansen, et al. Informational [Page 36]
2020RFC 5863 DKIM Development/Deployment/Operations May 2010
2023 that email cannot have a signature with d=companya.example because
2024 the ISP-1 servers have no access to Company A's private key. In
2025 ISP-1's case, it will have an ISP-1 signature, but for some other
2026 mail clients offering the same multiple address feature there might
2027 be no signature at all on the message.
2029 Another example might be the use of a forward article to a friend
2030 service. Most instances of these services today allow someone to
2031 send an article with their email address in the RFC5322.From to their
2032 designated recipient. If Joe used either of his two addresses
2033 (joe@companya.example or joe@isp1.example.com), the forwarder would
2034 be equally unable to sign with a corresponding domain. As in the
2035 mail client case, the forwarder can either sign as its own domain or
2036 put no signature on the message.
2038 A third example is the use of privately configured forwarding.
2039 Assume that Joe has another account at ISP-2, joe@isp-2.example.com,
2040 but he'd prefer to read his ISP-2 mail from his ISP-1 account. He
2041 sets up his ISP-2 account to forward all incoming mail to
2042 joe@isp1.example.com. Assume alice@companyb.example sends
2043 joe@isp-2.example.com an email. Depending on how companyb.example
2044 configured its signature, and depending on whether or not ISP-2
2045 modifies messages that it forwards, it is possible that when Alice's
2046 message is received in Joe's ISP-1 account, the original signature
2047 will fail verification.
20498.2. Protection of Internal Mail
2051 One identity is particularly amenable to easy and accurate
2052 assessment: the organization's own identity. Members of an
2053 organization tend to trust messages that purport to be from within
2054 that organization. However, Internet Mail does not provide a
2055 straightforward means of determining whether such mail is, in fact,
2056 from within the organization. DKIM can be used to remedy this
2057 exposure. If the organization signs all of its mail, then its
2058 boundary MTAs can look for mail purporting to be from the
2059 organization that does not contain a verifiable signature.
2061 Such mail can, in most cases, be presumed to be spurious. However,
2062 domain managers are advised to consider the ways that mail processing
2063 can modify messages in ways that will invalidate an existing DKIM
2064 signature: mailing lists, courtesy forwarders, and other paths that
2065 could add or modify headers or modify the message body (e.g., MTAs at
2066 hotels, hotspot networks used by traveling users, and other scenarios
2067 described in the previous section). Such breakage is particularly
2068 relevant in the presence of Author Domain Signing Practices.
2074Hansen, et al. Informational [Page 37]
2076RFC 5863 DKIM Development/Deployment/Operations May 2010
20798.3. Signature Granularity
2081 Although DKIM's use of domain names is optimized for a scope of
2082 organization-level signing, it is possible to administer subdomains
2083 or otherwise adjust signatures in a way that supports per-user
2084 identification. This user-level granularity can be specified in two
2085 ways: either by sharing the signing identity and specifying an
2086 extension to the i= value that has a per-user granularity or by
2087 creating and signing with unique per-user keys.
2089 A subdomain or local part in the i= tag needs to be treated as an
2090 opaque identifier and thus need not correspond directly to a DNS
2091 subdomain or be a specific user address.
2093 The primary way to sign with per-user keys requires each user to have
2094 a distinct DNS (sub)domain, where each distinct d= value has a key
2095 published. (It is possible, although not advised, to publish the
2096 same key in more than one distinct domain.)
2098 It is technically possible to publish per-user keys within a single
2099 domain or subdomain by utilizing different selector values. This is
2100 not advised and is unlikely to be treated uniquely by Assessors: the
2101 primary purpose of selectors is to facilitate key management, and the
2102 DKIM specification recommends against using them in determining or
2103 assessing identities.
2105 In most cases, it would be impractical to sign email on a per-user
2106 granularity. Such an approach would be
2108 likely to be ignored: In most cases today, if receivers are
2109 verifying DKIM signatures, they are in general taking the simplest
2110 possible approach. In many cases, maintaining reputation
2111 information at a per-user granularity is not interesting to them,
2112 in large part because the per-user volume is too small to be
2113 useful or interesting. So even if senders take on the complexity
2114 necessary to support per-user signatures, receivers are unlikely
2115 to retain anything more than the base domain reputation.
2117 difficult to manage: Any scheme that involves maintenance of a
2118 significant number of public keys might require infrastructure
2119 enhancements or extensive administrative expertise. For domains
2120 of any size, maintaining a valid per-user keypair, knowing when
2121 keys need to be revoked or added due to user attrition or
2122 onboarding, and the overhead of having the signing engine
2123 constantly swapping keys can create significant and often
2124 unnecessary management complexity. It is also important to note
2130Hansen, et al. Informational [Page 38]
2132RFC 5863 DKIM Development/Deployment/Operations May 2010
2135 that there is no way within the scope of the DKIM specification
2136 for a receiver to infer that a sender intends a per-user
2139 As mentioned before, what might make sense, however, is to use the
2140 infrastructure that enables finer granularity in signatures to
2141 identify segments smaller than a domain but much larger than a per-
2142 user segmentation. For example, a university might want to segment
2143 student, staff, and faculty mail into three distinct streams with
2144 differing reputations. This can be done by creating separate
2145 subdomains for the desired segments, and either specifying the
2146 subdomains in the i= tag of the DKIM Signature or by adding
2147 subdomains to the d= tag and assigning and signing with different
2148 keys for each subdomain.
2150 For those who choose to represent user-level granularity in
2151 signatures, the performance and management considerations above
2152 suggest that it would be more effective to do so by specifying a
2153 local part or subdomain extension in the i= tag rather than by
2154 extending the d= domain and publishing individual keys.
21568.4. Email Infrastructure Agents
2158 It is expected that the most common venue for a DKIM implementation
2159 will be within the infrastructure of an organization's email service,
2160 such as a department or a boundary MTA. What follows are some
2161 general recommendations for the Email Infrastructure.
2163 Outbound: An MSA (Mail Submission Agent) or an outbound MTA used
2164 for mail submission needs to ensure that the message sent is in
2165 compliance with the advertised email sending policy. It needs
2166 to also be able to generate an operator alert if it determines
2167 that the email messages do not comply with the published DKIM
2170 An MSA needs to be aware that some MUAs might add their own
2171 signatures. If the MSA needs to perform operations on a
2172 message to make it comply with its email sending policy, if at
2173 all possible, it needs to do so in a way that would not break
2176 MUAs equipped with the ability to sign ought not to be
2177 encouraged. In terms of security, MUAs are generally not under
2178 the direct control of those in responsible roles within an
2179 organization and are thus more vulnerable to attack and
2180 compromise, which would expose private signing keys to
2181 intruders and thus jeopardize the integrity and reputation of
2186Hansen, et al. Informational [Page 39]
2188RFC 5863 DKIM Development/Deployment/Operations May 2010
2191 Inbound: When an organization deploys DKIM, it needs to make
2192 sure that its email infrastructure components that do not have
2193 primary roles in DKIM handling do not modify message in ways
2194 that prevent subsequent verification.
2196 An inbound MTA or an MDA can incorporate an indication of the
2197 verification results into the message, such as using an
2198 Authentication-Results header field [RFC5451].
2200 Intermediaries: An email intermediary is both an inbound and
2201 outbound MTA. Each of the requirements outlined in the
2202 sections relating to MTAs apply. If the intermediary modifies
2203 a message in a way that breaks the signature, the intermediary.
2205 + needs to deploy abuse filtering measures on the inbound
2208 + probably also needs to remove all signatures that will be
2211 In addition, the intermediary can:
2213 + verify the message signature prior to modification.
2215 + incorporate an indication of the verification results into
2216 the message, such as using an Authentication-Results header
2219 + sign the modified message including the verification results
2220 (e.g., the Authentication-Results header field).
2224 The DKIM specification is expected to be used primarily between
2225 Boundary MTAs, or other infrastructure components of the originating
2226 and receiving ADMDs. However, there is nothing in DKIM that is
2227 specific to those venues. In particular, MUAs can also support DKIM
2228 signing and verifying directly.
2230 Outbound: An MUA can support signing even if mail is to be
2231 relayed through an outbound MSA. In this case, the signature
2232 applied by the MUA will be in addition to any signature added
2233 by the MSA. However, the warnings in the previous section need
2234 to be taken into consideration.
2242Hansen, et al. Informational [Page 40]
2244RFC 5863 DKIM Development/Deployment/Operations May 2010
2247 Some user software goes beyond simple user functionality and
2248 also performs MSA and MTA functions. When this is employed for
2249 sending directly to a receiving ADMD, the user software needs
2250 to be considered an outbound MTA.
2252 Inbound: An MUA can rely on a report of a DKIM signature
2253 verification that took place at some point in the inbound MTA/
2254 MDA path (e.g., an Authentication-Results header field), or an
2255 MUA can perform DKIM signature verification directly. A
2256 verifying MUA needs to allow for the case where mail has been
2257 modified in the inbound MTA path; if a signature fails, the
2258 message is to be treated the same as a message that does not
2261 An MUA that looks for an Authentication-Results header field
2262 needs to be configurable to choose which Authentication-Results
2263 header fields are considered trustable. The MUA developer is
2264 encouraged to re-read the Security Considerations of [RFC5451].
2266 DKIM requires that all verifiers treat messages with signatures
2267 that do not verify as if they are unsigned.
2269 If verification in the client is to be acceptable to users, it
2270 is essential that successful verification of a signature not
2271 result in a less than satisfactory user experience compared to
2272 leaving the message unsigned. The mere presence of a verified
2273 DKIM signature cannot be used by itself by an MUA to indicate
2274 that a message is to be treated better than a message without a
2275 verified DKIM signature. However, the fact that a DKIM
2276 signature was verified can be used as input into a reputation
2277 system (i.e., a whitelist of domains and users) for
2278 presentation of such indicators.
2280 It is common for components of an ADMD's email infrastructure to do
2281 violence to a message, such that a DKIM signature might be rendered
2282 invalid. Hence, users of MUAs that support DKIM signing and/or
2283 verifying need a basis for knowing that their associated email
2284 infrastructure will not break a signature.
22869. Security Considerations
2288 The security considerations of the DKIM protocol are described in the
2289 DKIM base specification [RFC4871].
2293 The effort of the DKIM Working Group is gratefully acknowledged.
2298Hansen, et al. Informational [Page 41]
2300RFC 5863 DKIM Development/Deployment/Operations May 2010
230511.1. Normative References
2307 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
2308 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
2309 Signatures", RFC 4871, May 2007.
2311 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
2314 [RFC5451] Kucherawy, M., "Message Header Field for Indicating
2315 Message Authentication Status", RFC 5451, April 2009.
2317 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
2318 Identified Mail (DKIM) Service Overview", RFC 5585,
2321 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
2322 "DomainKeys Identified Mail (DKIM) Author Domain Signing
2323 Practices (ADSP)", RFC 5617, August 2009.
2325 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
2326 Signatures -- Update", RFC 5672, August 2009.
232811.2. Informative References
2330 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
2331 Rose, "Resource Records for the DNS Security Extensions",
2332 RFC 4034, March 2005.
2334 [RFC4870] Delany, M., "Domain-Based Email Authentication Using
2335 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
2338 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
2339 Security (DNSSEC) Hashed Authenticated Denial of
2340 Existence", RFC 5155, March 2008.
2354Hansen, et al. Informational [Page 42]
2356RFC 5863 DKIM Development/Deployment/Operations May 2010
2359Appendix A. Migration Strategies
2361 There are three migration occasions worth noting in particular for
2364 1. Migrating from DomainKeys to DKIM.
2366 2. Migrating from a current hash algorithm to a new standardized
2369 3. Migrating from a current signing algorithm to a new standardized
2372 The case of deploying a new key selector record is described
2373 elsewhere (Section 3.5).
2375 As with any migration, the steps required will be determined by who
2376 is doing the migration and their assessment of:
2378 o the users of what they are generating, or
2380 o the providers of what they are consuming.
2382 Signers and verifiers have different considerations.
2384A.1. Migrating from DomainKeys
2386 DKIM replaces the earlier DomainKeys (DK) specification. Selector
2387 files are mostly compatible between the two specifications.
2391 A signer that currently signs with DK will go through various stages
2392 as it migrates to using DKIM, not all of which are required for all
2393 signers. The real questions that a signer needs to ask are:
2395 1. how many receivers or what types of receivers are *only* looking
2396 at the DK signatures and not the DKIM signatures, and
2398 2. how much does the signer care about those receivers?
2400 If no one is looking at the DK signature any more, then it's no
2401 longer necessary to sign with DK. Or if all "large players" are
2402 looking at DKIM in addition to or instead of DK, a signer can choose
2403 to stop signing with DK.
2410Hansen, et al. Informational [Page 43]
2412RFC 5863 DKIM Development/Deployment/Operations May 2010
2415 With respect to signing policies, a reasonable, initial approach is
2416 to use DKIM signatures in the same way that DomainKeys signatures are
2417 already being used. In particular, the same selectors and DNS key
2418 records can be used for both, after verifying that they are
2419 compatible as discussed below.
2421 Each secondary step in all of the following scenarios is to be
2422 prefaced with the gating factor "test, then when comfortable with the
2423 previous step's results, continue".
2425 One migration strategy is to:
2427 o ensure that the current selector DNS key record is compatible with
2430 o sign messages with both DK and DKIM signatures
2432 o when it's decided that DK signatures are no longer necessary, stop
2435 Another migration strategy is to:
2437 o add a new selector DNS key record only for DKIM signatures
2439 o sign messages with both DK (using the old DNS key record) and DKIM
2440 signatures (using the new DNS key record)
2442 o when it's decided that DK signatures are no longer necessary, stop
2445 o eventually remove the old DK selector DNS record
2447 A combined migration strategy is to:
2449 o ensure that the current selector DNS key record is compatible with
2452 o start signing messages with both DK and DKIM signatures
2454 o add a new selector DNS key record for DKIM signatures
2456 o switch the DKIM signatures to use the new selector
2458 o when it's decided that DK signatures are no longer necessary, stop
2461 o eventually remove the old DK selector DNS record
2466Hansen, et al. Informational [Page 44]
2468RFC 5863 DKIM Development/Deployment/Operations May 2010
2471 Another migration strategy is to:
2473 o add a new selector DNS key record for DKIM signatures
2475 o do a flash cut and replace the DK signatures with DKIM signatures
2477 o eventually remove the old DK selector DNS record
2479 Another migration strategy is to:
2481 o ensure that the current selector DNS key record is compatible with
2484 o do a flash cut and replace the DK signatures with DKIM signatures
2486 Note that when you have separate key records for DK and DKIM, you can
2487 use the same public key for both.
2489A.1.1.1. DNS Selector Key Records
2491 The first step in some of the above scenarios is ensuring that the
2492 selector DNS key records are compatible for both DK and DKIM. The
2493 format of the DNS key record was intentionally meant to be backwardly
2494 compatible between the two systems, but not necessarily upwardly
2495 compatible. DKIM has enhanced the DK DNS key record format by adding
2496 several optional parameters, which DK needs to ignore. However,
2497 there is one critical difference between DK and DKIM DNS key records.
2498 The definitions of the "g" fields:
2500 g= granularity of the key: In both DK and DKIM, this is an optional
2501 field that is used to constrain which sending address(es) can
2502 legitimately use this selector. Unfortunately, the treatment of
2503 an empty field ("g=;") is different. DKIM allows wildcards where
2504 DK does not. For DK, an empty field is the same as a missing
2505 value, and is treated as allowing any sending address. For DKIM,
2506 an empty field only matches an empty local part. In DKIM, both a
2507 missing value and "g=*;" mean to allow any sending address.
2509 Also, in DomainKeys, the "g" field is required to match the
2510 address in "From:"/"Sender:", while in DKIM, it is required to
2511 match i=. This might or might not affect transition.
2513 If your DK DNS key record has an empty "g" field in it ("g=;"),
2514 your best course of action is to modify the record to remove the
2515 empty field. In that way, the DK semantics will remain the same,
2516 and the DKIM semantics will match.
2522Hansen, et al. Informational [Page 45]
2524RFC 5863 DKIM Development/Deployment/Operations May 2010
2527 If your DNS key record does not have an empty "g" field in it
2528 ("g=;"), it's probable that the record can be left alone. But the
2529 best course of action would still be to make sure that it has a
2530 "v" field. When the decision is made to stop supporting
2531 DomainKeys and to only support DKIM, it is important to verify
2532 that the "g" field is compatible with DKIM, and typically having
2533 "v=DKIM1;" in it. It is strongly encouraged that if use of an
2534 empty "g" field in the DKIM selector, include the "v" field.
2536A.1.1.2. Removing DomainKeys Signatures
2538 The principal use of DomainKeys is at boundary MTAs. Because no
2539 operational transition is ever instantaneous, it is advisable to
2540 continue performing DomainKeys signing until it is determined that
2541 DomainKeys receive-side support is no longer used, or is sufficiently
2542 reduced. That is, a signer needs to add a DKIM signature to a
2543 message that also has a DomainKeys signature and keep it there until
2544 they decide it is deemed no longer useful. The signer can do its
2545 transitions in a straightforward manner, or more gradually. Note
2546 that because digital signatures are not free, there is a cost to
2547 performing both signing algorithms, so signing with both algorithms
2548 ought not be needlessly prolonged.
2550 The tricky part is deciding when DK signatures are no longer
2551 necessary. The real questions are: how many DomainKeys verifiers are
2552 there that do *not* also do DKIM verification, which of those are
2553 important, and how can you track their usage? Most of the early
2554 adopters of DK verification have added DKIM verification, but not all
2555 yet. If a verifier finds a message with both DK and DKIM, it can
2556 choose to verify both signatures, or just one or the other.
2558 Many DNS services offer tracking statistics so it can be determined
2559 how often a DNS record has been accessed. By using separate DNS
2560 selector key records for your signatures, you can chart the use of
2561 your records over time, and watch the trends. An additional
2562 distinguishing factor to track would take into account the verifiers
2563 that verify both the DK and DKIM signatures, and discount those from
2564 counts of DK selector usage. When the number for DK selector access
2565 reaches a low-enough level, that's the time to consider discontinuing
2568 Note, this level of rigor is not required. It is perfectly
2569 reasonable for a DK signer to decide to follow the "flash cut"
2570 scenario described above.
2578Hansen, et al. Informational [Page 46]
2580RFC 5863 DKIM Development/Deployment/Operations May 2010
2585 As a verifier, several issues need to be considered:
2587A.1.2.1. Ought DK signature verification be performed?
2589 At the time of writing, there is still a significant number of sites
2590 that are only producing DK signatures. Over time, it is expected
2591 that this number will go to zero, but it might take several years.
2592 So it would be prudent for the foreseeable future for a verifier to
2593 look for and verify both DKIM and DK signatures.
2595A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single
2598 For a period of time, there will be sites that sign with both DK and
2599 DKIM. A verifier receiving a message that has both types of
2600 signatures can verify both signatures, or just one. One disadvantage
2601 of verifying both signatures is that signers will have a more
2602 difficult time deciding how many verifiers are still using their DK
2603 selectors. One transition strategy is to verify the DKIM signature,
2604 then only verify the DK signature if the DKIM verification fails.
2606A.1.2.3. DNS Selector Key Records
2608 The format of the DNS key record was intentionally meant to be
2609 backwardly compatible between DK and DKIM, but not necessarily
2610 upwardly compatible. DKIM has enhanced the DK DNS key record format
2611 by adding several optional parameters, which DK needs to ignore.
2612 However, there is one key difference between DK and DKIM DNS key
2613 records. The definitions of the g fields:
2615 g= granularity of the key: In both DK and DKIM, this is an optional
2616 field that is used to constrain which sending address(es) can
2617 legitimately use this selector. Unfortunately, the treatment of
2618 an empty field ("g=;") is different. For DK, an empty field is
2619 the same as a missing value, and is treated as allowing any
2620 sending address. For DKIM, an empty field only matches an empty
2623 v= version of the selector It is advised that a DKIM selector have
2624 "v=DKIM1;" at its beginning, but it is not required.
2626 If a DKIM verifier finds a selector record that has an empty "g"
2627 field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
2628 beginning, it is faced with deciding if this record was:
2634Hansen, et al. Informational [Page 47]
2636RFC 5863 DKIM Development/Deployment/Operations May 2010
2639 1. from a DK signer that transitioned to supporting DKIM but forgot
2640 to remove the "g" field (so that it could be used by both DK and
2643 2. from a DKIM signer that truly meant to use the empty "g" field
2644 but forgot to put in the "v" field. It is advised that you treat
2645 such records using the first interpretation, and treat such
2646 records as if the signer did not have a "g" field in the record.
2648A.2. Migrating Hash Algorithms
2650 [RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256.
2651 The security of all hash algorithms is constantly under attack, and
2652 SHA-1 has already shown weaknesses as of this writing. Migrating
2653 from SHA-1 to SHA-256 is not an issue, because all verifiers are
2654 already required to support SHA-256. But when it becomes necessary
2655 to replace SHA-256 with a more secure algorithm, there will be a
2656 migratory period. In the following, "NEWHASH" is used to represent a
2657 new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this
2662 As with migrating from DK to DKIM, migrating hash algorithms is
2663 dependent on the signer's best guess as to the utility of continuing
2664 to sign with the older algorithms and the expected support for the
2665 newer algorithm by verifiers. The utility of continuing to sign with
2666 the older algorithms is also based on how broken the existing hash
2667 algorithms are considered and how important that is to the signers.
2669 One strategy is to wait until it's determined that there is a large
2670 enough base of verifiers available that support NEWHASH, and then
2671 flash cut to the new algorithm.
2673 Another strategy is to sign with both the old and new hash algorithms
2674 for a period of time. This is particularly useful for testing the
2675 new code to support the new hash algorithm, as verifiers will
2676 continue to accept the signature for the older hash algorithm and
2677 ought to ignore any signature that fails because the code is slightly
2678 wrong. Once the signer has determined that the new code is correct
2679 AND it's determined that there is a large enough base of verifiers
2680 available that support NEWHASH, the signer can flash cut to the new
2683 One advantage migrating hash algorithms has is that the selector can
2684 be completely compatible for all hash algorithms. The key selector
2685 has an optional "h=" field that can be used to list the hash
2686 algorithms being used; it also is used to limit the algorithms that a
2690Hansen, et al. Informational [Page 48]
2692RFC 5863 DKIM Development/Deployment/Operations May 2010
2695 verifier will accept. If the signer is not currently using the key
2696 selector "h=" field, no change is required. If the signer is
2697 currently using the key selector "h=" field, NEWHASH will need to be
2698 added to the list, as in "h=sha256:NEWHASH;". (When the signer is no
2699 longer using SHA-256, it can be removed from the "h=" list.)
2703 When a new hash algorithm becomes standardized, it is best for a
2704 verifier to start supporting it as quickly as possible.
2706A.3. Migrating Signing Algorithms
2708 [RFC4871] defines the use of the RSA signing algorithm. Similar to
2709 hashes, signing algorithms are constantly under attack, and when it
2710 becomes necessary to replace RSA with a newer signing algorithm,
2711 there will be a migratory period. In the following, "NEWALG" is used
2712 to represent a new signing algorithm.
2716 As with the other migration issues discussed above, migrating signing
2717 algorithms is dependent on the signer's best guess as to the utility
2718 of continuing to sign with the older algorithms and the expected
2719 support for the newer algorithm by verifiers. The utility of
2720 continuing to sign with the older algorithms is also based on how
2721 broken the existing signing algorithms are considered and how
2722 important that is to the signers.
2724 As before, the two basic strategies are to 1) wait until there is
2725 sufficient base of verifiers available that support NEWALG and then
2726 do a flash cut to NEWALG, and 2) use a phased approach by signing
2727 with both the old and new algorithms before removing support for the
2730 It is unlikely that a new algorithm would be able to use the same
2731 public key as "rsa", so using the same selector DNS record for both
2732 algorithms' keys is ruled out. Therefore, in order to use the new
2733 algorithm, a new DNS selector record would need to be deployed in
2734 parallel with the existing DNS selector record for the existing
2735 algorithm. The new DNS selector record would specify a different
2736 "k=" value to reflect the use of NEWALG.
2746Hansen, et al. Informational [Page 49]
2748RFC 5863 DKIM Development/Deployment/Operations May 2010
2753 When a new hash algorithm becomes standardized, it is best for a
2754 verifier to start supporting it as quickly as possible.
2756Appendix B. General Coding Criteria for Cryptographic Applications
2758 NOTE: This section could possibly be changed into a reference to
2759 something else, such as another RFC.
2761 Correct implementation of a cryptographic algorithm is a necessary
2762 but not a sufficient condition for the coding of cryptographic
2763 applications. Coding of cryptographic libraries requires close
2764 attention to security considerations that are unique to cryptographic
2767 In addition to the usual security coding considerations, such as
2768 avoiding buffer or integer overflow and underflow, implementers need
2769 to pay close attention to management of cryptographic private keys
2770 and session keys, ensuring that these are correctly initialized and
2773 Operating system mechanisms that permit the confidentiality of
2774 private keys to be protected against other processes ought to be used
2775 when available. In particular, great care needs to be taken when
2776 releasing memory pages to the operating system to ensure that private
2777 key information is not disclosed to other processes.
2779 Certain implementations of public key algorithms such as RSA can be
2780 vulnerable to a timing analysis attack.
2782 Support for cryptographic hardware providing key management
2783 capabilities is strongly encouraged. In addition to offering
2784 performance benefits, many cryptographic hardware devices provide
2785 robust and verifiable management of private keys.
2787 Fortunately, appropriately designed and coded cryptographic libraries
2788 are available for most operating system platforms under license terms
2789 compatible with commercial, open source and free software license
2790 terms. Use of standard cryptographic libraries is strongly
2791 encouraged. These have been extensively tested, reduce development
2792 time and support a wide range of cryptographic hardware.
2802Hansen, et al. Informational [Page 50]
2804RFC 5863 DKIM Development/Deployment/Operations May 2010
2811 200 Laurel Ave. South
2812 Middletown, NJ 07748
2815 EMail: tony+dkimov@maillennium.att.com
2821 EMail: dkim@esiegel.net
2824 Phillip Hallam-Baker
2825 Default Deny Security, Inc.
2827 EMail: phillip@hallambaker.com
2831 Brandenburg InternetWorking
2836 EMail: dcrocker@bbiw.net
2858Hansen, et al. Informational [Page 51]