3.  DKIM Key Generation, Storage, and Management

   By itself, verification of a digital signature only allows the
   verifier to conclude with a very high degree of certainty that the
   signature was created by a party with access to the corresponding
   private signing key.  It follows that a verifier requires means to
   (1) obtain the public key for the purpose of verification and (2)
   infer useful attributes of the key holder.

   In a traditional Public Key Infrastructure (PKI), the functions of
   key distribution and key accreditation are separated.  In DKIM
   [RFC4871], these functions are both performed through the DNS.

   In either case, the ability to infer semantics from a digital
   signature depends on the assumption that the corresponding private
   key is only accessible to a party with a particular set of
   attributes.  In a traditional PKI, a Trusted Third Party (TTP)
   vouches that the key holder has been validated with respect to a
   specified set of attributes.  The range of attributes that can be
   attested in such a scheme is thus limited only to the type of
   attributes that a TTP can establish effective processes for
   validating.  In DKIM, TTPs are not employed and the functions of key
   distribution and accreditation are combined.

   Consequently, there are only two types of inference that a signer can
   make from a key published in a DKIM key record:

   1.  That a party with the ability to control DNS records within a DNS
       zone intends to claim responsibility for messages signed using
       the corresponding private signature key.

   2.  That use of a specific key is restricted to the particular subset
       of messages identified by the selector.

   The ability to draw any useful conclusion from verification of a
   digital signature relies on the assumption that the corresponding
   private key is only accessible to a party with a particular set of

   attributes.  In the case of DKIM, this means that the party that
   created the corresponding DKIM key record in the specific zone
   intended to claim responsibility for the signed message.

   Ideally, we would like to draw a stronger conclusion, that if we
   obtain a DKIM key record from the DNS zone example.com, that the
   legitimate holder of the DNS zone example.com claims responsibility
   for the signed message.  In order for this conclusion to be drawn, it
   is necessary for the verifier to assume that the operational security
   of the DNS zone and corresponding private key are adequate.

3.1.  Private Key Management: Deployment and Ongoing Operations

   Access to signing keys needs to be carefully managed to prevent use
   by unauthorized parties and to minimize the consequences if a
   compromise were to occur.

   While a DKIM signing key is used to sign messages on behalf of many
   mail users, the signing key itself needs to be under direct control
   of as few key holders as possible.  If a key holder were to leave the
   organization, all signing keys held by that key holder need to be
   withdrawn from service and, if appropriate, replaced.

   If key management hardware support is available, it needs to be used.
   If keys are stored in software, appropriate file control protections
   need to be employed, and any location in which the private key is
   stored in plaintext form needs to be excluded from regular backup
   processes and is best not accessible through any form of network
   including private local area networks.  Auditing software needs to be
   used periodically to verify that the permissions on the private key
   files remain secure.

   Wherever possible, a signature key needs to exist in exactly one
   location and be erased when no longer used.  Ideally, a signature key
   pair needs to be generated as close to the signing point as possible,
   and only the public key component transferred to another party.  If
   this is not possible, the private key needs to be transported in an
   encrypted format that protects the confidentiality of the signing
   key.  A shared directory on a local file system does not provide
   adequate security for distribution of signing keys in plaintext form.

   Key escrow schemes are not necessary and are best not used.  In the
   unlikely event of a signing key becoming lost, a new signature key
   pair can be generated as easily as recovery from a key escrow scheme.

   To enable accountability and auditing:

   o  Responsibility for the security of a signing key needs to
      ultimately vest in a single named individual.

   o  Where multiple parties are authorized to sign messages, each
      signer needs to use a different key to enable accountability and
      auditing.

   Best practices for management of cryptographic keying material
   require keying material to be refreshed at regular intervals,
   particularly where key management is achieved through software.
   While this practice is highly desirable, it is of considerably less
   importance than the requirement to maintain the secrecy of the
   corresponding private key.  An operational practice in which the
   private key is stored in tamper-proof hardware and changed once a
   year is considerably more desirable than one in which the signature
   key is changed on an hourly basis but maintained in software.

3.2.  Storing Public Keys: DNS Server Software Considerations

   In order to use DKIM, a DNS domain holder requires (1) the ability to
   create the necessary DKIM DNS records and (2) sufficient operational
   security controls to prevent insertion of spurious DNS records by an
   attacker.

   DNS record management is often operated by an administrative staff
   that is different from those who operate an organization's email
   service.  In order to ensure that DKIM DNS records are accurate, this
   imposes a requirement for careful coordination between the two
   operations groups.  If the best practices for private key management
   described above are observed, such deployment is not a one-time
   event; DNS DKIM selectors will be changed over time as signing keys
   are terminated and replaced.

   At a minimum, a DNS server that handles queries for DKIM key records
   needs to allow the server administrators to add free-form TXT
   records.  It would be better if the DKIM records could be entered
   using a structured form, supporting the DKIM-specific fields.

   Ideally, DNS Security (DNSSEC) [RFC4034] needs to be employed in a
   configuration that provides protection against record insertion
   attacks and zone enumeration.  In the case that NextSECure version 3
   (NSEC3) [RFC5155] records are employed to prevent insertion attack,
   the OPT-OUT flag needs to be clear.  (See [RFC5155] section 6 for
   details.)

3.2.1.  Assignment of Selectors

   Selectors are assigned according to the administrative needs of the
   signing domain, such as for rolling over to a new key or for the
   delegation of the right to authenticate a portion of the namespace to
   a TTP.  Examples include:

   jun2005.eng._domainkey.example.com

   widget.promotion._domainkey.example.com

   It is intended that assessments of DKIM identities be based on the
   domain name, and not include the selector.  While past practice of a
   signer can permit a verifier to infer additional properties of
   particular messages from the structure DKIM key selector, unannounced
   administrative changes such as a change of signing software can cause
   such heuristics to fail at any time.

3.3.  Per-User Signing Key Management Issues

   While a signer can establish business rules, such as the issue of
   individual signature keys for each end-user, DKIM makes no provision
   for communicating these to other parties.  Out-of-band distribution
   of such business rules is outside the scope of DKIM.  Consequently,
   there is no means by which external parties can make use of such keys
   to attribute messages with any greater granularity than a DNS domain.

   If per-user signing keys are assigned for internal purposes (e.g.,
   authenticating messages sent to an MTA (Mail Transfer Agent) for
   distribution), the following issues need to be considered before
   using such signatures as an alternative to traditional edge signing
   at the outbound MTA:

      External verifiers will be unable to make use of the additional
      signature granularity without access to additional information
      passed out of band with respect to [RFC4871].

      If the number of user keys is large, the efficiency of local
      caching of key records by verifiers will be lower.

      A large number of end users is be less likely to do an adequate
      job of managing private key data securely on their personal
      computers than is an administrator running an edge MTA.

3.4.  Third-Party Signer Key Management and Selector Administration

   A DKIM key record only asserts that the holder of the corresponding
   domain name makes a claim of responsibility for messages signed under
   the corresponding key.  In some applications, such as bulk mail
   delivery, it is desirable to delegate use of the key.  That is, to
   allow a third party to sign on behalf of the domain holder.  The
   trust relationship is still established between the domain holder and
   the verifier, but the private signature key is held by a third party.

   Signature keys used by a third-party signer need to be kept entirely
   separate from those used by the domain holder and other third-party
   signers.  To limit potential exposure of the private key, the
   signature key pair needs to be generated by the third-party signer
   and the public component of the key transmitted to the domain holder,
   rather than have the domain holder generate the key pair and transmit
   the private component to the third-party signer.

   Domain holders needs to adopt a least-privilege approach and grant
   third-party signers the minimum access necessary to perform the
   desired function.  Limiting the access granted to third-party signers
   serves to protect the interests of both parties.  The domain holder
   minimizes its security risk and the TTP signer avoids unnecessary
   liability.

   In the most restrictive case, domain holders maintain full control
   over the creation of key records.  They can employ appropriate key
   record restrictions to enforce limits on the messages for which the
   third-party signer is able to sign.  If such restrictions are
   impractical, the domain holder needs to delegate a DNS subzone for
   publishing key records to the third-party signer.  It is best that
   the domain holder NOT allow a third-party signer unrestricted access
   to its DNS service for the purpose of publishing key records.

3.5.  Key Pair / Selector Life Cycle Management

   Deployments need to establish, document, and observe processes for
   managing the entire life cycle of an asymmetric key pair.

3.5.1.  Example Key Deployment Process

   When it is determined that a new key pair is required:

   1.  A Key Pair is generated by the signing device.

   2.  A proposed key selector record is generated and transmitted to
       the DNS administration infrastructure.

   3.  The DNS administration infrastructure verifies the authenticity
       of the key selector registration request.  If accepted:

       1.  A key selector is assigned.

       2.  The corresponding key record is published in the DNS.

       3.  Wait for DNS updates to propagate (if necessary).

       4.  Report assigned key selector to signing device.

   4.  The signer verifies correct registration of the key record.

   5.  The signer begins generating signatures using the new key pair.

   6.  The signer terminates any private keys that are no longer
       required due to issue of replacement.

3.5.2.  Example Key Termination Process

   When it is determined that a private signature key is no longer
   required:

   1.  The signer stops using the private key for signature operations.

   2.  The signer deletes all records of the private key, including in-
       memory copies at the signing device.

   3.  The signer notifies the DNS administration infrastructure that
       the signing key is withdrawn from service and that the
       corresponding key records can be withdrawn from service at a
       specified future date.

   4.  The DNS administration infrastructure verifies the authenticity
       of the key selector termination request.  If accepted,

       1.  The key selector is scheduled for deletion at a future time
           determined by site policy.

       2.  Wait for deletion time to arrive.

       3.  The signer either publishes a revocation key selector with an
           empty public-key data (p=) field, or deletes the key selector
           record entirely.

   5.  As far as the verifier is concerned, there is no functional
       difference between verifying against a key selector with an empty
       p= field, and verifying against a missing key selector: both

       result in a failed signature and the signature needs to be
       treated as if it had not been there.  However, there is a minor
       semantic difference: with the empty p= field, the signer is
       explicitly stating that the key has been revoked.  The empty p=
       record provides a gravestone for an old selector, making it less
       likely that the selector might be accidentally reused with a
       different public key.

4.  Signing

   Creating messages that have one or more DKIM signatures requires
   support in only two outbound email service components:

   o  A DNS Administrative interface that can create and maintain the
      relevant DNS names -- including names with underscores -- and
      resource records (RR).

   o  A trusted module, called the signing module, which is within the
      organization's outbound email handling service and which creates
      and adds the DKIM-Signature: header field(s) to the message.

   If the module creates more than one signature, there needs to be the
   appropriate means of telling it which one(s) to use.  If a large
   number of names are used for signing, it will help to have the
   administrative tool support a batch-processing mode.

4.1.  DNS Records

   A receiver attempting to verify a DKIM signature obtains the public
   key that is associated with the signature for that message.  The
   DKIM-Signature: header in the message contains the d= tag with the
   basic domain name doing the signing and serving as output to the
   Identity Assessor and the s= tag with the selector that is added to
   the name, for finding the specific public key.  Hence, the relevant
   <selector>._domainkey.<domain-name> DNS record needs to contain a
   DKIM-related RR that provides the public key information.

   The administrator of the zone containing the relevant domain name
   adds this information.  Initial DKIM DNS information is contained
   within TXT RRs.  DNS administrative software varies considerably in
   its abilities to support DKIM names, such as with underscores, and to
   add new types of DNS information.

4.2.  Signing Module

   The module doing signing can be placed anywhere within an
   organization's trusted Administrative Management Domain (ADMD);
   obvious choices include department-level posting agents, as well as

   outbound boundary MTAs to the open Internet.  However, any other
   module, including the author's MUA (Mail User Agent), is potentially
   acceptable, as long as the signature survives any remaining handling
   within the ADMD.  Hence, the choice among the modules depends upon
   software development, administrative overhead, security exposures,
   and transit-handling tradeoffs.  One perspective that helps to
   resolve this choice is the difference between the increased
   flexibility, from placement at (or close to) the MUA, versus the
   streamlined administration and operation that is more easily obtained
   by implementing the mechanism "deeper" into the organization's email
   infrastructure, such as at its boundary MTA.

   Note the discussion in Section 2.2 concerning the use of the i= tag.

   The signing module uses the appropriate private key to create one or
   more signatures.  (See Section 6.5 for a discussion of multiple
   signatures.)  The means by which the signing module obtains the
   private key(s) is not specified by DKIM.  Given that DKIM is intended
   for use during email transit, rather than for long-term storage, it
   is expected that keys will be changed regularly.  For administrative
   convenience, it is best not to hard-code key information into
   software.

4.3.  Signing Policies and Practices

   Every organization (ADMD) will have its own policies and practices
   for deciding when to sign messages (message stream) and with what
   domain name, selector, and key.  Examples of particular message
   streams include all mail sent from the ADMD versus mail from
   particular types of user accounts versus mail having particular types
   of content.  Given this variability, and the likelihood that signing
   practices will change over time, it will be useful to have these
   decisions represented through run-time configuration information,
   rather than being hard-coded into the signing software.

   As noted in Section 2.3, the choice of signing name granularity
   requires balancing administrative convenience and utility for
   recipients.  Too much granularity is higher administrative overhead
   and might well attempt to impose more differential analysis on the
   recipient than they wish to support.  In such cases, they are likely
   to use only a super-name -- right-hand substring -- of the signing
   name.  When this occurs, the signer will not know what portion is
   being used; this then moves DKIM back to the non-deterministic world
   of heuristics, rather than the mechanistic world of signer/recipient
   collaboration that DKIM seeks.

5.  Verifying

   A message recipient can verify a DKIM signature to determine if a
   claim of responsibility has been made for the message by a trusted
   domain.

   Access control requires two components: authentication and
   authorization.  By design, verification of a DKIM signature only
   provides the authentication component of an access control decision
   and needs to be combined with additional sources of information such
   as reputation data to arrive at an access control decision.

5.1.  Intended Scope of Use

   DKIM requires that a message with a signature that is found to be
   invalid is to be treated as if the message had not been signed at
   all.

   If a DKIM signature fails to verify, it is entirely possible that the
   message is valid and that either there is a configuration error in
   the signer's system (e.g., a missing key record) or that the message
   was inadvertently modified in transit.  It is thus undesirable for
   mail infrastructure to treat messages with invalid signatures less
   favorably than those with no signatures whatsoever.  Contrariwise,
   creation of an invalid signature requires a trivial amount of effort
   on the part of an attacker.  If messages with invalid signatures were
   to be treated preferentially to messages with no signatures
   whatsoever, attackers will simply add invalid signature blocks to
   gain the preferential treatment.  It follows that messages with
   invalid signatures need to be treated no better and no worse than
   those with no signature at all.

5.2.  Signature Scope

   As with any other digital signature scheme, verifiers need to
   consider only the part of the message that is inside the scope of the
   message as being authenticated by the signature.

   For example, if the l= option is employed to specify a content length
   for the scope of the signature, only the part of the message that is
   within the scope of the content signature would be considered
   authentic.

5.3.  Design Scope of Use

   Public key cryptography provides an exceptionally high degree of
   assurance, bordering on absolute certainty, that the party that
   created a valid digital signature had access to the private key
   corresponding to the public key indicated in the signature.

   In order to make useful conclusions from the verification of a valid
   digital signature, the verifier is obliged to make assumptions that
   fall far short of absolute certainty.  Consequently, mere validation
   of a DKIM signature does not represent proof positive that a valid
   claim of responsibility was made for it by the indicated party, that
   the message is authentic, or that the message is not abusive.  In
   particular:

   o  The legitimate private key holder might have lost control of its
      private key.

   o  The legitimate domain holder might have lost control of the DNS
      server for the zone from which the key record was retrieved.

   o  The key record might not have been delivered from the legitimate
      DNS server for the zone from which the key record was retrieved.

   o  Ownership of the DNS zone might have changed.

   In practice, these limitations have little or no impact on the field
   of use for which DKIM is designed, but they can have a bearing if use
   is made of the DKIM message signature format or key retrieval
   mechanism in other specifications.

   In particular, the DKIM key retrieval mechanism is designed for ease
   of use and deployment rather than to provide a high assurance Public
   Key Infrastructure suitable for purposes that require robust non-
   repudiation such as establishing legally binding contracts.
   Developers seeking to extend DKIM beyond its design application need
   to consider replacing or supplementing the DNS key retrieval
   mechanism with one that is designed to meet the intended purposes.

5.4.  Inbound Mail Filtering

   DKIM is frequently employed in a mail filtering strategy to avoid
   performing content analysis on email originating from trusted
   sources.  Messages that carry a valid DKIM signature from a trusted
   source can be whitelisted, avoiding the need to perform computation
   and hence energy-intensive content analysis to determine the
   disposition of the message.

   Mail sources can be determined to be trusted by means of previously
   observed behavior and/or reference to external reputation or
   accreditation services.  The precise means by which this is
   accomplished is outside the scope of DKIM.

5.4.1.  Non-Verifying Adaptive Spam Filtering Systems

   Adaptive (or learning) spam filtering mechanisms that are not capable
   of verifying DKIM signatures need to, at minimum, be configured to
   ignore DKIM header data entirely.

5.5.  Messages Sent through Mailing Lists and Other Intermediaries

   Intermediaries, such as mailing lists, pose a particular challenge
   for DKIM implementations, as the message processing steps performed
   by the intermediary can cause the message content to change in ways
   that prevent the signature passing verification.

   Such intermediaries are strongly encouraged to deploy DKIM signing so
   that a verifiable claim of responsibility remains available to
   parties attempting to verify the modified message.

5.6.  Generation, Transmission, and Use of Results Headers

   In many deployments, it is desirable to separate signature
   verification from the application relying on the verification.  A
   system can choose to relay information indicating the results of its
   message authentication efforts using various means; adding a "results
   header" to the message is one such mechanism [RFC5451].  For example,
   consider the cases where:

   o  The application relying on DKIM signature verification is not
      capable of performing the verification.

   o  The message can be modified after the signature verification is
      performed.

   o  The signature key cannot be available by the time that the message
      is read.

   In such cases, it is important that the communication link between
   the signature verifier and the relying application be sufficiently
   secure to prevent insertion of a message that carries a bogus results
   header.

   An intermediary that generates results headers need to ensure that
   relying applications are able to distinguish valid results headers
   issued by the intermediary from those introduced by an attacker.  For

   example, this can be accomplished by signing the results header.  At
   a minimum, results headers on incoming messages need to be removed if
   they purport to have been issued by the intermediary but cannot be
   verified as authentic.

   Further discussion on trusting the results as relayed from a verifier
   to something downstream can be found in [RFC5451].

6.  Taxonomy of Signatures

   As described in Section 2.1, a DKIM signature tells the signature
   verifier that the owner of a particular domain name accepts some
   responsibility for the message.  It does not, in and of itself,
   provide any information about the trustworthiness or behavior of that
   identity.  What it does provide is a verified identity to which such
   behavioral information can be associated, so that those who collect
   and use such information can be assured that it truly pertains to the
   identity in question.

   This section lays out a taxonomy of some of the different identities,
   or combinations of identities, that might usefully be represented by
   a DKIM signature.

6.1.  Single Domain Signature

   Perhaps the simplest case is when an organization signs its own
   outbound email using its own domain in the SDID [RFC5672] of the
   signature.  For example, Company A would sign the outbound mail from
   its employees with d=companyA.example.

   In the most straightforward configuration, the addresses in the
   RFC5322.From field would also be in the companyA.example domain, but
   that direct correlation is not required.

   A special case of the single domain signature is an author signature
   as defined by the Author Domain Signing Practices specification
   [RFC5617].  Author signatures are signatures from an author's
   organization that have an SDID value that matches that of an
   RFC5322.From address of the signed message.

   Although an author signature might, in some cases, be proof against
   spoofing the domain name of the RFC5322.From address, it is important
   to note that the DKIM and ADSP validation apply only to the exact
   address string and not to look-alike addresses or to the human-
   friendly "display-name" or names and addresses used within the body
   of the message.  That is, it only protects against the misuse of a
   precise address string within the RFC5322.From field and nothing
   else.  For example, a message from bob@domain.example with a valid

   signature where d=d0main.example would fail an ADSP check because the
   signature domain, however similar, is distinct; however, a message
   from bob@d0main.example with a valid signature where d=d0main.example
   would pass an ADSP check, even though to a human it might be obvious
   that d0main.example is likely a malicious attempt to spoof the domain
   domain.example.  This example highlights that ADSP, like DKIM, is
   only able to validate a signing identifier: it still requires some
   external process to attach a meaningful reputation to that
   identifier.

6.2.  Parent Domain Signature

   Another approach that might be taken by an organization with multiple
   active subdomains is to apply the same (single) signature domain to
   mail from all subdomains.  In this case, the signature chosen would
   usually be the signature of a parent domain common to all subdomains.
   For example, mail from marketing.domain.example,
   sales.domain.example, and engineering.domain.example might all use a
   signature where d=domain.example.

   This approach has the virtue of simplicity, but it is important to
   consider the implications of such a choice.  As discussed in
   Section 2.3, if the type of mail sent from the different subdomains
   is significantly different or if there is reason to believe that the
   reputation of the subdomains would differ, then it can be a good idea
   to acknowledge this and provide distinct signatures for each of the
   subdomains (d=marketing.domain.example, sales.domain.example, etc.).
   However, if the mail and reputations are likely to be similar, then
   the simpler approach of using a single common parent domain in the
   signature can work well.

   Another approach to distinguishing the streams using a single DKIM
   key would be to leverage the AUID [RFC5672] (i= tag) in the DKIM
   signature to differentiate the mail streams.  For example, marketing
   email would be signed with i=@marketing.domain.example and
   d=domain.example.

   It's important to remember, however, that under core DKIM semantics,
   the AUID is opaque to receivers.  That means that it will only be an
   effective differentiator if there is an out-of-band agreement about
   the i= semantics.

6.3.  Third-Party Signature

   A signature whose domain does not match the domain of the
   RFC5322.From address is sometimes referred to as a third-party
   signature.  In certain cases, even the parent domain signature

   described above would be considered a third-party signature because
   it would not be an exact match for the domain in the RFC5322.From
   address.

   Although there is often heated debate about the value of third party
   signatures, it is important to note that the DKIM specification
   attaches no particular significance to the identity in a DKIM
   signature ([RFC4871], [RFC5672]).  The identity specified within the
   signature is the identity that is taking responsibility for the
   message, and it is only the interpretation of a given receiver that
   gives one identity more or less significance than another.  In
   particular, most independent reputation services assign trust based
   on the specific identifier string, not its "role": in general they
   make no distinction between, for example, an author signature and a
   third-party signature.

   For some, a signature unrelated to the author domain (the domain in
   the RFC5322.From address) is less valuable because there is an
   assumption that the presence of an author signature guarantees that
   the use of the address in the RFC5322.From header is authorized.

   For others, that relevance is tied strictly to the recorded
   behavioral data assigned to the identity in question, i.e., its trust
   assessment or reputation.  The reasoning here is that an identity
   with a good reputation is unlikely to maintain that good reputation
   if it is in the habit of vouching for messages that are unwanted or
   abusive; in fact, doing so will rapidly degrade its reputation so
   that future messages will no longer benefit from it.  It is therefore
   low risk to facilitate the delivery of messages that contain a valid
   signature of a domain with a strong positive reputation, independent
   of whether or not that domain is associated with the address in the
   RFC5322.From header field of the message.

   Third-party signatures encompass a wide range of identities.  Some of
   the more common are:

   Service Provider:  In cases where email is outsourced to an Email
      Service Provider (ESP), Internet Service Provider (ISP), or other
      type of service provider, that service provider can choose to
      DKIM-sign outbound mail with either its own identifier -- relying
      on its own, aggregate reputation -- or with a subdomain of the
      provider that is unique to the message author but still part of
      the provider's aggregate reputation.  Such service providers can
      also encompass delegated business functions such as benefit
      management, although these will more often be treated as trusted
      third-party senders (see below).

   Parent Domain:  As discussed above, organizations choosing to apply a
      parent-domain signature to mail originating from subdomains can
      have their signatures treated as third party by some verifiers,
      depending on whether or not the "t=s" tag is used to constrain the
      parent signature to apply only to its own specific domain.  The
      default is to consider a parent-domain signature valid for its
      subdomains.

   Reputation Provider:  Another possible category of third-party
      signature would be the identity of a third-party reputation
      provider.  Such a signature would indicate to receivers that the
      message was being vouched for by that third party.

6.4.  Using Trusted Third-Party Senders

   For most of the cases described so far, there has been an assumption
   that the signing agent was responsible for creating and maintaining
   its own DKIM signing infrastructure, including its own keys, and
   signing with its own identity.

   A different model arises when an organization uses a trusted third-
   party sender for certain key business functions, but still wants that
   email to benefit from the organization's own identity and reputation.
   In other words, the mail would come out of the trusted third party's
   mail servers, but the signature applied would be that of the
   controlling organization.

   This can be done by having the third party generate a key pair that
   is designated uniquely for use by that trusted third party and
   publishing the public key in the controlling organization's DNS
   domain, thus enabling the third party to sign mail using the
   signature of the controlling organization.  For example, if Company A
   outsources its employee benefits to a third party, it can use a
   special key pair that enables the benefits company to sign mail as
   "companyA.example".  Because the key pair is unique to that trusted
   third party, it is easy for Company A to revoke the authorization if
   necessary by simply removing the public key from the companyA.example
   DNS.

   A more cautious approach would be to create a dedicated subdomain
   (e.g., benefits.companyA.example) to segment the outsourced mail
   stream, and to publish the public key there; the signature would then
   use d=benefits.companyA.example.

6.4.1.  DNS Delegation

   Another possibility for configuring trusted third-party access, as
   discussed in Section 3.4, is to have Company A use DNS delegation and
   have the designated subdomain managed directly by the trusted third
   party.  In this case, Company A would create a subdomain
   benefits.companya.example, and delegate the DNS management of that
   subdomain to the benefits company so it could maintain its own key
   records.  When revocation becomes necessary, Company A could simply
   remove the DNS delegation record.

6.5.  Multiple Signatures

   A simple configuration for DKIM-signed mail is to have a single
   signature on a given message.  This works well for domains that
   manage and send all of their own email from single sources, or for
   cases where multiple email streams exist but each has its own unique
   key pair.  It also represents the case in which only one of the
   participants in an email sequence is able to sign, no matter whether
   it represents the author or one of the operators.

   The examples thus far have considered the implications of using
   different identities in DKIM signatures, but have used only one such
   identity for any given message.  In some cases, it can make sense to
   have more than one identity claiming responsibility for the same
   message.

   There are a number of situations where applying more than one DKIM
   signature to the same message might make sense.  A few examples are:

   Companies with multiple subdomain identities:  A company that has
      multiple subdomains sending distinct categories of mail might
      choose to sign with distinct subdomain identities to enable each
      subdomain to manage its own identity.  However, it might also want
      to provide a common identity that cuts across all of the distinct
      subdomains.  For example, Company A can sign mail for its sales
      department with a signature where d=sales.companya.example and a
      second signature where d=companya.example

   Service Providers:  A service provider can, as described above,
      choose to sign outbound messages with either its own identity or
      an identity unique to each of its clients (possibly delegated).
      However, it can also do both: sign each outbound message with its
      own identity as well as with the identity of each individual
      client.  For example, ESP A might sign mail for its client Company
      B with its service provider signature d=espa.example, and a second
      client-specific signature where d= either companyb.example or
      companyb.espa.example.  The existence of the service provider

      signature could, for example, help cover a new client while it
      establishes its own reputation, or help a very small volume client
      who might never reach a volume threshold sufficient to establish
      an individual reputation.

   Forwarders:  Forwarded mail poses a number of challenges to email
      authentication.  DKIM is relatively robust in the presence of
      forwarders as long as the signature is designed to avoid message
      parts that are likely to be modified; however, some forwarders do
      make modifications that can invalidate a DKIM signature.

      Some forwarders such as mailing lists or "forward article to a
      friend" services might choose to add their own signatures to
      outbound messages to vouch for them having legitimately originated
      from the designated service.  In this case, the signature would be
      added even in the presence of a preexisting signature, and both
      signatures would be relevant to the verifier.

      Any forwarder that modifies messages in ways that will break
      preexisting DKIM signatures needs to sign its forwarded messages.

   Reputation Providers:  Although third-party reputation providers
      today use a variety of protocols to communicate their information
      to receivers, it is possible that they, or other organizations
      willing to put their "seal of approval" on an email stream, might
      choose to use a DKIM signature to do it.  In nearly all cases,
      this "reputation" signature would be in addition to the author or
      originator signature.

   One important caveat to the use of multiple signatures is that there
   is currently no clear consensus among receivers on how they plan to
   handle them.  The opinions range from ignoring all but one signature
   (and the specification of which of them is verified differs from
   receiver to receiver), to verifying all signatures present and
   applying a weighted blend of the trust assessments for those
   identifiers, to verifying all signatures present and simply using the
   identifier that represents the most positive trust assessment.  It is
   likely that the industry will evolve to accept multiple signatures
   using either the second or third of these, but it can take some time
   before one approach becomes pervasive.