Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4871


DomainKeys Identified Mail (DKIM) Signatures

Part 4 of 4, p. 52 to 71
Prev RFC Part


prevText      Top      Up      ToC       Page 52 
8.  Security Considerations

   It has been observed that any mechanism that is introduced that
   attempts to stem the flow of spam is subject to intensive attack.
   DKIM needs to be carefully scrutinized to identify potential attack
   vectors and the vulnerability to each.  See also [RFC4686].

8.1.  Misuse of Body Length Limits ("l=" Tag)

   Body length limits (in the form of the "l=" tag) are subject to
   several potential attacks.

8.1.1.  Addition of New MIME Parts to Multipart/*

   If the body length limit does not cover a closing MIME multipart
   section (including the trailing "--CRLF" portion), then it is
   possible for an attacker to intercept a properly signed multipart
   message and add a new body part.  Depending on the details of the
   MIME type and the implementation of the verifying MTA and the
   receiving MUA, this could allow an attacker to change the information
   displayed to an end user from an apparently trusted source.

Top      Up      ToC       Page 53 
   For example, if attackers can append information to a "text/html"
   body part, they may be able to exploit a bug in some MUAs that
   continue to read after a "</html>" marker, and thus display HTML text
   on top of already displayed text.  If a message has a
   "multipart/alternative" body part, they might be able to add a new
   body part that is preferred by the displaying MUA.

8.1.2.  Addition of new HTML content to existing content

   Several receiving MUA implementations do not cease display after a
   ""</html>"" tag.  In particular, this allows attacks involving
   overlaying images on top of existing text.

      INFORMATIVE EXAMPLE: Appending the following text to an existing,
      properly closed message will in many MUAs result in inappropriate
      data being rendered on top of existing, correct data:
   <div style="position: relative; bottom: 350px; z-index: 2;">
   <img src=""
     width=578 height=370>

8.2.  Misappropriated Private Key

   If the private key for a user is resident on their computer and is
   not protected by an appropriately secure mechanism, it is possible
   for malware to send mail as that user and any other user sharing the
   same private key.  The malware would not, however, be able to
   generate signed spoofs of other signers' addresses, which would aid
   in identification of the infected user and would limit the
   possibilities for certain types of attacks involving socially
   engineered messages.  This threat applies mainly to MUA-based
   implementations; protection of private keys on servers can be easily
   achieved through the use of specialized cryptographic hardware.

   A larger problem occurs if malware on many users' computers obtains
   the private keys for those users and transmits them via a covert
   channel to a site where they can be shared.  The compromised users
   would likely not know of the misappropriation until they receive
   "bounce" messages from messages they are purported to have sent.
   Many users might not understand the significance of these bounce
   messages and would not take action.

   One countermeasure is to use a user-entered passphrase to encrypt the
   private key, although users tend to choose weak passphrases and often
   reuse them for different purposes, possibly allowing an attack
   against DKIM to be extended into other domains.  Nevertheless, the
   decoded private key might be briefly available to compromise by
   malware when it is entered, or might be discovered via keystroke

Top      Up      ToC       Page 54 
   logging.  The added complexity of entering a passphrase each time one
   sends a message would also tend to discourage the use of a secure

   A somewhat more effective countermeasure is to send messages through
   an outgoing MTA that can authenticate the submitter using existing
   techniques (e.g., SMTP Authentication), possibly validate the message
   itself (e.g., verify that the header is legitimate and that the
   content passes a spam content check), and sign the message using a
   key appropriate for the submitter address.  Such an MTA can also
   apply controls on the volume of outgoing mail each user is permitted
   to originate in order to further limit the ability of malware to
   generate bulk email.

8.3.  Key Server Denial-of-Service Attacks

   Since the key servers are distributed (potentially separate for each
   domain), the number of servers that would need to be attacked to
   defeat this mechanism on an Internet-wide basis is very large.
   Nevertheless, key servers for individual domains could be attacked,
   impeding the verification of messages from that domain.  This is not
   significantly different from the ability of an attacker to deny
   service to the mail exchangers for a given domain, although it
   affects outgoing, not incoming, mail.

   A variation on this attack is that if a very large amount of mail
   were to be sent using spoofed addresses from a given domain, the key
   servers for that domain could be overwhelmed with requests.  However,
   given the low overhead of verification compared with handling of the
   email message itself, such an attack would be difficult to mount.

8.4.  Attacks Against the DNS

   Since the DNS is a required binding for key services, specific
   attacks against the DNS must be considered.

   While the DNS is currently insecure [RFC3833], these security
   problems are the motivation behind DNS Security (DNSSEC) [RFC4033],
   and all users of the DNS will reap the benefit of that work.

   DKIM is only intended as a "sufficient" method of proving
   authenticity.  It is not intended to provide strong cryptographic
   proof about authorship or contents.  Other technologies such as
   OpenPGP [RFC2440] and S/MIME [RFC3851] address those requirements.

   A second security issue related to the DNS revolves around the
   increased DNS traffic as a consequence of fetching selector-based
   data as well as fetching signing domain policy.  Widespread

Top      Up      ToC       Page 55 
   deployment of DKIM will result in a significant increase in DNS
   queries to the claimed signing domain.  In the case of forgeries on a
   large scale, DNS servers could see a substantial increase in queries.

   A specific DNS security issue that should be considered by DKIM
   verifiers is the name chaining attack described in Section 2.3 of the
   DNS Threat Analysis [RFC3833].  A DKIM verifier, while verifying a
   DKIM-Signature header field, could be prompted to retrieve a key
   record of an attacker's choosing.  This threat can be minimized by
   ensuring that name servers, including recursive name servers, used by
   the verifier enforce strict checking of "glue" and other additional
   information in DNS responses and are therefore not vulnerable to this

8.5.  Replay Attacks

   In this attack, a spammer sends a message to be spammed to an
   accomplice, which results in the message being signed by the
   originating MTA.  The accomplice resends the message, including the
   original signature, to a large number of recipients, possibly by
   sending the message to many compromised machines that act as MTAs.
   The messages, not having been modified by the accomplice, have valid

   Partial solutions to this problem involve the use of reputation
   services to convey the fact that the specific email address is being
   used for spam and that messages from that signer are likely to be
   spam.  This requires a real-time detection mechanism in order to
   react quickly enough.  However, such measures might be prone to
   abuse, if for example an attacker resent a large number of messages
   received from a victim in order to make them appear to be a spammer.

   Large verifiers might be able to detect unusually large volumes of
   mails with the same signature in a short time period.  Smaller
   verifiers can get substantially the same volume of information via
   existing collaborative systems.

8.6.  Limits on Revoking Keys

   When a large domain detects undesirable behavior on the part of one
   of its users, it might wish to revoke the key used to sign that
   user's messages in order to disavow responsibility for messages that
   have not yet been verified or that are the subject of a replay
   attack.  However, the ability of the domain to do so can be limited
   if the same key, for scalability reasons, is used to sign messages
   for many other users.  Mechanisms for explicitly revoking keys on a
   per-address basis have been proposed but require further study as to
   their utility and the DNS load they represent.

Top      Up      ToC       Page 56 
8.7.  Intentionally Malformed Key Records

   It is possible for an attacker to publish key records in DNS that are
   intentionally malformed, with the intent of causing a denial-of-
   service attack on a non-robust verifier implementation.  The attacker
   could then cause a verifier to read the malformed key record by
   sending a message to one of its users referencing the malformed
   record in a (not necessarily valid) signature.  Verifiers MUST
   thoroughly verify all key records retrieved from the DNS and be
   robust against intentionally as well as unintentionally malformed key

8.8.  Intentionally Malformed DKIM-Signature Header Fields

   Verifiers MUST be prepared to receive messages with malformed DKIM-
   Signature header fields, and thoroughly verify the header field
   before depending on any of its contents.

8.9.  Information Leakage

   An attacker could determine when a particular signature was verified
   by using a per-message selector and then monitoring their DNS traffic
   for the key lookup.  This would act as the equivalent of a "web bug"
   for verification time rather than when the message was read.

8.10.  Remote Timing Attacks

   In some cases, it may be possible to extract private keys using a
   remote timing attack [BONEH03].  Implementations should consider
   obfuscating the timing to prevent such attacks.

8.11.  Reordered Header Fields

   Existing standards allow intermediate MTAs to reorder header fields.
   If a signer signs two or more header fields of the same name, this
   can cause spurious verification errors on otherwise legitimate
   messages.  In particular, signers that sign any existing DKIM-
   Signature fields run the risk of having messages incorrectly fail to

8.12.  RSA Attacks

   An attacker could create a large RSA signing key with a small
   exponent, thus requiring that the verification key have a large
   exponent.  This will force verifiers to use considerable computing
   resources to verify the signature.  Verifiers might avoid this attack
   by refusing to verify signatures that reference selectors with public
   keys having unreasonable exponents.

Top      Up      ToC       Page 57 
   In general, an attacker might try to overwhelm a verifier by flooding
   it with messages requiring verification.  This is similar to other
   MTA denial-of-service attacks and should be dealt with in a similar

8.13.  Inappropriate Signing by Parent Domains

   The trust relationship described in Section 3.8 could conceivably be
   used by a parent domain to sign messages with identities in a
   subdomain not administratively related to the parent.  For example,
   the ".com" registry could create messages with signatures using an
   "i=" value in the domain.  There is no general solution
   to this problem, since the administrative cut could occur anywhere in
   the domain name.  For example, in the domain ""
   there are three administrative cuts (,, and us),
   any of which could create messages with an identity in the full

      INFORMATIVE NOTE: This is considered an acceptable risk for the
      same reason that it is acceptable for domain delegation.  For
      example, in the example above any of the domains could potentially
      simply delegate "" to a server of their choice
      and completely replace all DNS-served information.  Note that a
      verifier MAY ignore signatures that come from an unlikely domain
      such as ".com", as discussed in Section 6.1.1.

9.  References

9.1.  Normative References

   [FIPS.180-2.2002]  U.S. Department of Commerce, "Secure Hash
                      Standard", FIPS PUB 180-2, August 2002.

   [ITU.X660.1997]    "Information Technology - ASN.1 encoding rules:
                      Specification of Basic Encoding Rules (BER),
                      Canonical Encoding Rules (CER) and Distinguished
                      Encoding Rules (DER)", ITU-T Recommendation X.660,

   [RFC2045]          Freed, N. and N. Borenstein, "Multipurpose
                      Internet Mail Extensions (MIME) Part One: Format
                      of Internet Message Bodies", RFC 2045,
                      November 1996.

   [RFC2047]          Moore, K., "MIME (Multipurpose Internet Mail
                      Extensions) Part Three: Message header field
                      Extensions for Non-ASCII Text", RFC 2047,
                      November 1996.

Top      Up      ToC       Page 58 
   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

   [RFC2821]          Klensin, J., "Simple Mail Transfer Protocol",
                      RFC 2821, April 2001.

   [RFC2822]          Resnick, P., "Internet Message Format", RFC 2822,
                      April 2001.

   [RFC3447]          Jonsson, J. and B. Kaliski, "Public-Key
                      Cryptography Standards (PKCS) #1: RSA Cryptography
                      Specifications Version 2.1", RFC 3447,
                      February 2003.

   [RFC3490]          Faltstrom, P., Hoffman, P., and A. Costello,
                      "Internationalizing Domain Names in Applications
                      (IDNA)", RFC 3490, March 2003.

   [RFC4234]          Crocker, D., Ed. and P. Overell, "Augmented BNF
                      for Syntax Specifications: ABNF", RFC 4234,
                      October 2005.

9.2.  Informative References

   [BONEH03]          Proc. 12th USENIX Security Symposium, "Remote
                      Timing Attacks are Practical", 2003.

   [RFC1847]          Galvin, J., Murphy, S., Crocker, S., and N. Freed,
                      "Security Multiparts for MIME: Multipart/Signed
                      and Multipart/Encrypted", RFC 1847, October 1995.

   [RFC2434]          Narten, T. and H. Alvestrand, "Guidelines for
                      Writing an IANA Considerations Section in RFCs",
                      BCP 26, RFC 2434, October 1998.

   [RFC2440]          Callas, J., Donnerhacke, L., Finney, H., and R.
                      Thayer, "OpenPGP Message Format", RFC 2440,
                      November 1998.

   [RFC3766]          Orman, H. and P. Hoffman, "Determining Strengths
                      for Public Keys Used For Exchanging Symmetric
                      Keys", RFC 3766, April 2004.

   [RFC3833]          Atkins, D. and R. Austein, "Threat Analysis of the
                      Domain Name System (DNS)", RFC 3833, August 2004.

Top      Up      ToC       Page 59 
   [RFC3851]          Ramsdell, B., "S/MIME Version 3 Message
                      Specification", RFC 3851, June 1999.

   [RFC3864]          Klyne, G., Nottingham, M., and J. Mogul,
                      "Registration Procedures for Message Header
                      Fields", BCP 90, September 2004.

   [RFC4033]          Arends, R., Austein, R., Larson, M., Massey, D.,
                      and S. Rose, "DNS Security Introduction and
                      Requirements", RFC 4033, March 2005.

   [RFC4686]          Fenton, J., "Analysis of Threats Motivating
                      DomainKeys Identified Mail (DKIM)", RFC 4686,
                      September 2006.

   [RFC4870]          Delany, M., "Domain-Based Email Authentication
                      Using Public Keys Advertised in the DNS
                      (DomainKeys)", RFC 4870, May 2007.

Top      Up      ToC       Page 60 
Appendix A.  Example of Use (INFORMATIVE)

   This section shows the complete flow of an email from submission to
   final delivery, demonstrating how the various components fit
   together.  The key used in this example is shown in Appendix C.

A.1.  The User Composes an Email

   From: Joe SixPack <>
   To: Suzie Q <>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <>


   We lost the game. Are you hungry yet?


Top      Up      ToC       Page 61 
A.2.  The Email Is Signed

   This email is signed by the outbound email server and now
   looks like this:

   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane;;
         c=simple/simple; q=dns/txt;;
         h=Received : From : To : Subject : Date : Message-ID;
   Received: from  []
         by with SUBMISSION;
         Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <>
   To: Suzie Q <>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <>


   We lost the game. Are you hungry yet?


   The signing email server requires access to the private key
   associated with the "brisbane" selector to generate this signature.

A.3.  The Email Signature Is Verified

   The signature is normally verified by an inbound SMTP server or
   possibly the final delivery agent.  However, intervening MTAs can
   also perform this verification if they choose to do so.  The
   verification process uses the domain "" extracted from the
   "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM-
   Signature header field to form the DNS DKIM query for:

   Signature verification starts with the physically last Received
   header field, the From header field, and so forth, in the order
   listed in the "h=" tag.  Verification follows with a single CRLF
   followed by the body (starting with "Hi.").  The email is canonically
   prepared for verifying with the "simple" method.  The result of the
   query and subsequent verification of the signature is stored (in this

Top      Up      ToC       Page 62 
   example) in the X-Authentication-Results header field line.  After
   successful verification, the email looks like this:

   X-Authentication-Results:; dkim=pass
   Received: from (
         by with SMTP;
         Fri, 11 Jul 2003 21:01:59 -0700 (PDT)
   DKIM-Signature: v=1; a=rsa-sha256; s=brisbane;;
         c=simple/simple; q=dns/txt;;
         h=Received : From : To : Subject : Date : Message-ID;
   Received: from  []
         by with SUBMISSION;
         Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
   From: Joe SixPack <>
   To: Suzie Q <>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <>


   We lost the game. Are you hungry yet?


Appendix B.  Usage Examples (INFORMATIVE)

   DKIM signing and validating can be used in different ways, for
   different operational scenarios.  This Appendix discusses some common

      NOTE: Descriptions in this Appendix are for informational purposes
      only.  They describe various ways that DKIM can be used, given
      particular constraints and needs.  In no case are these examples
      intended to be taken as providing explanation or guidance
      concerning DKIM specification details, when creating an

Top      Up      ToC       Page 63 
B.1.  Alternate Submission Scenarios

   In the most simple scenario, a user's MUA, MSA, and Internet
   (boundary) MTA are all within the same administrative environment,
   using the same domain name.  Therefore, all of the components
   involved in submission and initial transfer are related.  However, it
   is common for two or more of the components to be under independent
   administrative control.  This creates challenges for choosing and
   administering the domain name to use for signing, and for its
   relationship to common email identity header fields.

B.1.1.  Delegated Business Functions

   Some organizations assign specific business functions to discrete
   groups, inside or outside the organization.  The goal, then, is to
   authorize that group to sign some mail, but to constrain what
   signatures they can generate.  DKIM selectors (the "s=" signature
   tag) and granularity (the "g=" key tag) facilitate this kind of
   restricted authorization.  Examples of these outsourced business
   functions are legitimate email marketing providers and corporate
   benefits providers.

   Here, the delegated group needs to be able to send messages that are
   signed, using the email domain of the client company.  At the same
   time, the client often is reluctant to register a key for the
   provider that grants the ability to send messages for arbitrary
   addresses in the domain.

   There are multiple ways to administer these usage scenarios.  In one
   case, the client organization provides all of the public query
   service (for example, DNS) administration, and in another it uses DNS
   delegation to enable all ongoing administration of the DKIM key
   record by the delegated group.

   If the client organization retains responsibility for all of the DNS
   administration, the outsourcing company can generate a key pair,
   supplying the public key to the client company, which then registers
   it in the query service, using a unique selector that authorizes a
   specific From header field Local-part.  For example, a client with
   the domain "" could have the selector record specify
   "g=winter-promotions" so that this signature is only valid for mail
   with a From address of "".  This would
   enable the provider to send messages using that specific address and
   have them verify properly.  The client company retains control over
   the email address because it retains the ability to revoke the key at
   any time.

Top      Up      ToC       Page 64 
   If the client wants the delegated group to do the DNS administration,
   it can have the domain name that is specified with the selector point
   to the provider's DNS server.  The provider then creates and
   maintains all of the DKIM signature information for that selector.
   Hence, the client cannot provide constraints on the Local-part of
   addresses that get signed, but it can revoke the provider's signing
   rights by removing the DNS delegation record.

B.1.2.  PDAs and Similar Devices

   PDAs demonstrate the need for using multiple keys per domain.
   Suppose that John Doe wanted to be able to send messages using his
   corporate email address,, and his email device did
   not have the ability to make a Virtual Private Network (VPN)
   connection to the corporate network, either because the device is
   limited or because there are restrictions enforced by his Internet
   access provider.  If the device was equipped with a private key
   registered for by the administrator of the domain, and appropriate software to sign messages, John
   could sign the message on the device itself before transmission
   through the outgoing network of the access service provider.

B.1.3.  Roaming Users

   Roaming users often find themselves in circumstances where it is
   convenient or necessary to use an SMTP server other than their home
   server; examples are conferences and many hotels.  In such
   circumstances, a signature that is added by the submission service
   will use an identity that is different from the user's home system.

   Ideally, roaming users would connect back to their home server using
   either a VPN or a SUBMISSION server running with SMTP AUTHentication
   on port 587.  If the signing can be performed on the roaming user's
   laptop, then they can sign before submission, although the risk of
   further modification is high.  If neither of these are possible,
   these roaming users will not be able to send mail signed using their
   own domain key.

B.1.4.  Independent (Kiosk) Message Submission

   Stand-alone services, such as walk-up kiosks and web-based
   information services, have no enduring email service relationship
   with the user, but users occasionally request that mail be sent on
   their behalf.  For example, a website providing news often allows the
   reader to forward a copy of the article to a friend.  This is
   typically done using the reader's own email address, to indicate who
   the author is.  This is sometimes referred to as the "Evite problem",

Top      Up      ToC       Page 65 
   named after the website of the same name that allows a user to send
   invitations to friends.

   A common way this is handled is to continue to put the reader's email
   address in the From header field of the message, but put an address
   owned by the email posting site into the Sender header field.  The
   posting site can then sign the message, using the domain that is in
   the Sender field.  This provides useful information to the receiving
   email site, which is able to correlate the signing domain with the
   initial submission email role.

   Receiving sites often wish to provide their end users with
   information about mail that is mediated in this fashion.  Although
   the real efficacy of different approaches is a subject for human
   factors usability research, one technique that is used is for the
   verifying system to rewrite the From header field, to indicate the
   address that was verified.  For example: From: John Doe via <>.  (Note that such rewriting
   will break a signature, unless it is done after the verification pass
   is complete.)

B.2.  Alternate Delivery Scenarios

   Email is often received at a mailbox that has an address different
   from the one used during initial submission.  In these cases, an
   intermediary mechanism operates at the address originally used and it
   then passes the message on to the final destination.  This mediation
   process presents some challenges for DKIM signatures.

B.2.1.  Affinity Addresses

   "Affinity addresses" allow a user to have an email address that
   remains stable, even as the user moves among different email
   providers.  They are typically associated with college alumni
   associations, professional organizations, and recreational
   organizations with which they expect to have a long-term
   relationship.  These domains usually provide forwarding of incoming
   email, and they often have an associated Web application that
   authenticates the user and allows the forwarding address to be
   changed.  However, these services usually depend on users sending
   outgoing messages through their own service providers' MTAs.  Hence,
   mail that is signed with the domain of the affinity address is not
   signed by an entity that is administered by the organization owning
   that domain.

   With DKIM, affinity domains could use the Web application to allow
   users to register per-user keys to be used to sign messages on behalf
   of their affinity address.  The user would take away the secret half

Top      Up      ToC       Page 66 
   of the key pair for signing, and the affinity domain would publish
   the public half in DNS for access by verifiers.

   This is another application that takes advantage of user-level
   keying, and domains used for affinity addresses would typically have
   a very large number of user-level keys.  Alternatively, the affinity
   domain could handle outgoing mail, operating a mail submission agent
   that authenticates users before accepting and signing messages for
   them.  This is of course dependent on the user's service provider not
   blocking the relevant TCP ports used for mail submission.

B.2.2.  Simple Address Aliasing (.forward)

   In some cases, a recipient is allowed to configure an email address
   to cause automatic redirection of email messages from the original
   address to another, such as through the use of a Unix .forward file.
   In this case, messages are typically redirected by the mail handling
   service of the recipient's domain, without modification, except for
   the addition of a Received header field to the message and a change
   in the envelope recipient address.  In this case, the recipient at
   the final address' mailbox is likely to be able to verify the
   original signature since the signed content has not changed, and DKIM
   is able to validate the message signature.

B.2.3.  Mailing Lists and Re-Posters

   There is a wide range of behaviors in services that take delivery of
   a message and then resubmit it.  A primary example is with mailing
   lists (collectively called "forwarders" below), ranging from those
   that make no modification to the message itself, other than to add a
   Received header field and change the envelope information, to those
   that add header fields, change the Subject header field, add content
   to the body (typically at the end), or reformat the body in some
   manner.  The simple ones produce messages that are quite similar to
   the automated alias services.  More elaborate systems essentially
   create a new message.

   A Forwarder that does not modify the body or signed header fields of
   a message is likely to maintain the validity of the existing
   signature.  It also could choose to add its own signature to the

   Forwarders which modify a message in a way that could make an
   existing signature invalid are particularly good candidates for
   adding their own signatures (e.g.,
   Since (re-)signing is taking responsibility for the content of the
   message, these signing forwarders are likely to be selective, and
   forward or re-sign a message only if it is received with a valid

Top      Up      ToC       Page 67 
   signature or if they have some other basis for knowing that the
   message is not spoofed.

   A common practice among systems that are primarily redistributors of
   mail is to add a Sender header field to the message, to identify the
   address being used to sign the message.  This practice will remove
   any preexisting Sender header field as required by [RFC2822].  The
   forwarder applies a new DKIM-Signature header field with the
   signature, public key, and related information of the forwarder.

Appendix C.  Creating a Public Key (INFORMATIVE)

   The default signature is an RSA signed SHA256 digest of the complete
   email.  For ease of explanation, the openssl command is used to
   describe the mechanism by which keys and signatures are managed.  One
   way to generate a 1024-bit, unencrypted private key suitable for DKIM
   is to use openssl like this:

   $ openssl genrsa -out rsa.private 1024

   For increased security, the "-passin" parameter can also be added to
   encrypt the private key.  Use of this parameter will require entering
   a password for several of the following steps.  Servers may prefer to
   use hardware cryptographic support.

   The "genrsa" step results in the file rsa.private containing the key
   information similar to this:

    -----END RSA PRIVATE KEY-----

   To extract the public-key component from the private key, use openssl
   like this:

   $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Top      Up      ToC       Page 68 
   This results in the file rsa.public containing the key information
   similar to this:

   -----BEGIN PUBLIC KEY-----
   -----END PUBLIC KEY-----

   This public-key data (without the BEGIN and END tags) is placed in
   the DNS:


Appendix D.  MUA Considerations

   When a DKIM signature is verified, the processing system sometimes
   makes the result available to the recipient user's MUA.  How to
   present this information to the user in a way that helps them is a
   matter of continuing human factors usability research.  The tendency
   is to have the MUA highlight the address associated with this signing
   identity in some way, in an attempt to show the user the address from
   which the mail was sent.  An MUA might do this with visual cues such
   as graphics, or it might include the address in an alternate view, or
   it might even rewrite the original From address using the verified
   information.  Some MUAs might indicate which header fields were
   protected by the validated DKIM signature.  This could be done with a
   positive indication on the signed header fields, with a negative
   indication on the unsigned header fields, by visually hiding the
   unsigned header fields, or some combination of these.  If an MUA uses
   visual indications for signed header fields, the MUA probably needs
   to be careful not to display unsigned header fields in a way that
   might be construed by the end user as having been signed.  If the
   message has an l= tag whose value does not extend to the end of the
   message, the MUA might also hide or mark the portion of the message
   body that was not signed.

   The aforementioned information is not intended to be exhaustive.  The
   MUA may choose to highlight, accentuate, hide, or otherwise display
   any other information that may, in the opinion of the MUA author, be
   deemed important to the end user.

Top      Up      ToC       Page 69 
Appendix E.  Acknowledgements

   The authors wish to thank Russ Allbery, Edwin Aoki, Claus Assmann,
   Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin,
   Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman,
   Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto,
   Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur
   Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman,
   Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig
   Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S.
   Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon
   Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau,
   Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada,
   Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud,
   Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector
   Santos, Jim Schaad, the team, Malte S. Stretz, Robert
   Sanders, Rand Wacker, Sam Weiler, and Dan Wing for their valuable
   suggestions and constructive criticism.

   The DomainKeys specification was a primary source from which this
   specification has been derived.  Further information about DomainKeys
   is at [RFC4870].

Authors' Addresses

   Eric Allman
   Sendmail, Inc.
   6425 Christie Ave, Suite 400
   Emeryville, CA  94608

   Phone: +1 510 594 5501

   Jon Callas
   PGP Corporation
   3460 West Bayshore
   Palo Alto, CA  94303

   Phone: +1 650 319 9016

Top      Up      ToC       Page 70 
   Mark Delany
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA  95087

   Phone: +1 408 349 6831

   Miles Libbey
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA  95087


   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-9/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 526 5914

   Michael Thomas
   Cisco Systems, Inc.
   MS SJ-9/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone: +1 408 525 5386

Top      Up      ToC       Page 71 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is currently provided by the
   Internet Society.