Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6376

DomainKeys Identified Mail (DKIM) Signatures

Pages: 76
Internet Standard: 76
Obsoletes:  48715672
Updated by:  8301846385538616
Part 4 of 4 – Pages 55 to 76
First   Prev   None

Top   ToC   RFC6376 - Page 55   prevText

8. Security Considerations

It has been observed that any introduced mechanism 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. ASCII Art Attacks

The relaxed body canonicalization algorithm may enable certain types of extremely crude "ASCII Art" attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the "simple" body canonicalization algorithm should be used instead.

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

Use of the "l=" tag might allow display of fraudulent content without appropriate warning to end users. The "l=" tag is intended for increasing signature robustness when sending to mailing lists that both modify their content and do not sign their modified messages. However, using the "l=" tag enables attacks in which an intermediary with malicious intent can modify a message to include content that solely benefits the attacker. It is possible for the appended
Top   ToC   RFC6376 - Page 56
   content to completely replace the original content in the end
   recipient's eyes and to defeat duplicate message detection

   An example of such an attack includes altering the MIME structure,
   exploiting lax HTML parsing in the MUA, and defeating duplicate
   message detection algorithms.

   To avoid this attack, Signers should be extremely wary of using this
   tag, and Assessors might wish to ignore signatures that use the tag.

8.3. Misappropriated Private Key

As with any other security application that uses private- or public- key pairs, DKIM requires caution around the handling and protection of keys. A compromised private key or access to one means an intruder or malware can send mail signed by the domain that advertises the matching public key. Thus, private keys issued to users, rather than one used by an ADministrative Management Domain (ADMD) itself, create the usual problem of securing data stored on personal resources that can affect the ADMD. A more secure architecture involves sending 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.4. 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 involves a very large amount of mail being sent using spoofed signatures from a given domain: the key servers for that domain could be overwhelmed with requests in a denial-of-
Top   ToC   RFC6376 - Page 57
   service attack (see [RFC4732]).  However, given the low overhead of
   verification compared with handling of the email message itself, such
   an attack would be difficult to mount.

8.5. 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 [RFC4880] and S/MIME [RFC5751] 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 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 [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 attack.

8.6. Replay/Spam Attacks

In this attack, a spammer sends a piece of spam through an MTA that signs it, banking on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own, and then re- sends that message to a large number of intended recipients. The recipients observe the valid signature from the well-known domain, elevating their trust in the message and increasing the likelihood of delivery and presentation to the user. 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
Top   ToC   RFC6376 - Page 58
   react quickly enough.  However, such measures might be prone to
   abuse, if, for example, an attacker re-sent a large number of
   messages received from a victim in order to make the victim 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.7. 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.

8.8. 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 records.

8.9. 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.10. 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 the time the message was read.
Top   ToC   RFC6376 - Page 59

8.11. 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.12. 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 verify.

8.13. 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. 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 fashion.

8.14. Inappropriate Signing by Parent Domains

The trust relationship described in Section 3.10 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 domain. INFORMATIVE NOTE: This is considered an acceptable risk for the same reason that it is acceptable for domain delegation. For example, in the case above, any of the domains could potentially simply delegate "" to a server of their choice
Top   ToC   RFC6376 - Page 60
      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.

8.15. Attacks Involving Extra Header Fields

Many email components, including MTAs, MSAs, MUAs, and filtering modules, implement message format checks only loosely. This is done out of years of industry pressure to be liberal in what is accepted into the mail stream for the sake of reducing support costs; improperly formed messages are often silently fixed in transit, delivered unrepaired, or displayed inappropriately (e.g., by showing only the first of multiple From: fields). Agents that evaluate or apply DKIM output need to be aware that a DKIM Signer can sign messages that are malformed (e.g., violate [RFC5322], such as by having multiple instances of a field that is only permitted once), that become malformed in transit, or that contain header or body content that is not true or valid. Use of DKIM on such messages might constitute an attack against a receiver, especially where additional credence is given to a signed message without adequate evaluation of the Signer. These can represent serious attacks, but they have nothing to do with DKIM; they are attacks on the recipient or on the wrongly identified author. Moreover, an agent would be incorrect to infer that all instances of a header field are signed just because one is. A genuine signature from the domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the Signer list the field name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This, in essence, is an explicit indication that the Signer repudiates responsibility for such a malformed message. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the "d=" value) and, given the semantics of a DKIM signature, essentially the Signer has taken some responsibility for a problematic message. It is up to the Identity Assessor or some other
Top   ToC   RFC6376 - Page 61
   subsequent agent to act on such messages as needed, such as degrading
   the trust of the message (or, indeed, of the Signer), warning the
   recipient, or even refusing delivery.

   All components of the mail system that perform loose enforcement of
   other mail standards will need to revisit that posture when
   incorporating DKIM, especially when considering matters of potential
   attacks such as those described.

9. References

9.1. Normative References

[FIPS-180-3-2008] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3, October 2008. [ITU-X660-1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 1997. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
Top   ToC   RFC6376 - Page 62
   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

9.2. Informative References

[BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th USENIX Security Symposium, 2003. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006.
Top   ToC   RFC6376 - Page 63
   [RFC4870]  Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              May 2007.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

   [RFC5585]  Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
              Identified Mail (DKIM) Service Overview", RFC 5585,
              July 2009.

   [RFC5672]  Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
              Signatures -- Update", RFC 5672, August 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5863]  Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
              "DomainKeys Identified Mail (DKIM) Development,
              Deployment, and Operations", RFC 5863, May 2010.

   [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
              Mailing Lists", RFC 6377, September 2011.
Top   ToC   RFC6376 - Page 64

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: <> Hi. We lost the game. Are you hungry yet? Joe. Figure 1: The User Composes an Email
Top   ToC   RFC6376 - Page 65

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; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; 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: <> Hi. We lost the game. Are you hungry yet? Joe. Figure 2: The Email is Signed The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature.
Top   ToC   RFC6376 - Page 66

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 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; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; 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: <> Hi. We lost the game. Are you hungry yet? Joe. Figure 3: Successful Verification
Top   ToC   RFC6376 - Page 67

Appendix B. Usage Examples (INFORMATIVE)

DKIM signing and validating can be used in different ways, for different operational scenarios. This Appendix discusses some common examples. 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 implementation.

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) 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.
Top   ToC   RFC6376 - Page 68
   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.  The client company
   retains control over the use of the delegated key because it retains
   the ability to revoke the key at any time.

   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 wants to be able to send messages using his corporate email address,, and his email device does 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 is 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.
Top   ToC   RFC6376 - Page 69

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, 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 news@news-site.example <>. (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
Top   ToC   RFC6376 - Page 70
   changed.  However, these services usually depend on users sending
   outgoing messages through their own service provider's 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
   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.
Top   ToC   RFC6376 - Page 71
   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 that 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 signature or if
   they have some other basis for knowing that the message is not

   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 [RFC5322].  The
   forwarder applies a new DKIM-Signature header field with the
   signature, public key, and related information of the forwarder.

   See [RFC6377] for additional related topics and discussion.

Appendix C. Creating a Public Key (INFORMATIVE)

The default signature is an RSA-signed SHA-256 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:
Top   ToC   RFC6376 - Page 72
   -----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

   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:


C.1. Compatibility with DomainKeys Key Records

DKIM key records were designed to be backward compatible in many cases with key records used by DomainKeys [RFC4870] (sometimes referred to as "selector records" in the DomainKeys context). One area of incompatibility warrants particular attention. The "g=" tag value may be used in DomainKeys and [RFC4871] key records to provide
Top   ToC   RFC6376 - Page 73
   finer granularity of the validity of the key record to a specific
   local-part.  A null "g=" value in DomainKeys is valid for all
   addresses in the domain.  This differs from the usage in the original
   DKIM specification ([RFC4871]), where a null "g=" value is not valid
   for any address.  In particular, see the example public-key record in
   Section 3.2.3 of [RFC4870].

C.2. RFC 4871 Compatibility

Although the "g=" tag has been deprecated in this version of the DKIM specification (and thus MUST now be ignored), Signers are advised not to include the "g=" tag in key records because some [RFC4871]- compliant Verifiers will be in use for a considerable period to come.

Appendix D. MUA Considerations (INFORMATIVE)

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 users in a way that helps them is a matter of continuing human factors usability research. The tendency is to have the MUA highlight the SDID, in an attempt to show the user the identity that is claiming responsibility for the message. An MUA might do this with visual cues such as graphics, might include the address in an alternate view, or 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 can 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.

Appendix E. Changes since RFC 4871

o Abstract and introduction refined based on accumulated experience. o Various references updated.
Top   ToC   RFC6376 - Page 74
   o  Several errata resolved (see

      *  1376 applied

      *  1377 applied

      *  1378 applied

      *  1379 applied

      *  1380 applied

      *  1381 applied

      *  1382 applied

      *  1383 discarded (no longer applies)

      *  1384 applied

      *  1386 applied

      *  1461 applied

      *  1487 applied

      *  1532 applied

      *  1596 applied

   o  Introductory section enumerating relevant architectural documents

   o  Introductory section briefly discussing the matter of data
      integrity added.

   o  Allowed tolerance of some clock drift.

   o  Dropped "g=" tag from key records.  The implementation report
      indicates that it is not in use.

   o  Removed errant note about wildcards in the DNS.

   o  Removed SMTP-specific advice in most places.

   o  Reduced (non-normative) recommended signature content list, and
      reworked the text in that section.
Top   ToC   RFC6376 - Page 75
   o  Clarified signature generation algorithm by rewriting its pseudo-

   o  Numerous terminology subsections added, imported from [RFC5672].
      Also, began using these terms throughout the document (e.g., SDID,

   o  Sections added that specify input and output requirements.  Input
      requirements address a security concern raised by the working
      group (see also new sections in Security Considerations).  Output
      requirements are imported from [RFC5672].

   o  Appendix subsection added discussing compatibility with DomainKeys
      ([RFC4870]) records.

   o  Referred to [RFC5451] as an example method of communicating the
      results of DKIM verification.

   o  Removed advice about possible uses of the "l=" signature tag.

   o  IANA registry updated.

   o  Added two new Security Considerations sections talking about
      malformed message attacks.

   o  Various copy editing.

Appendix F. Acknowledgments

The previous IETF version of DKIM [RFC4871] was edited by Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton, and Michael Thomas. That specification was the result of an extended collaborative effort, including participation by 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 Gudmundsson, 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
Top   ToC   RFC6376 - Page 76
   Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam
   Weiler, and Dan Wing.

   The earlier DomainKeys was a primary source from which DKIM was
   derived.  Further information about DomainKeys is at [RFC4870].

   This revision received contributions from Steve Atkins, Mark Delany,
   J.D. Falk, Jim Fenton, Michael Hammer, Barry Leiba, John Levine,
   Charles Lindsey, Jeff Macdonald, Franck Martin, Brett McDowell, Doug
   Otis, Bill Oxley, Hector Santos, Rolf Sonneveld, Michael Thomas, and
   Alessandro Vesely.

Authors' Addresses

Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 EMail: URI: Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA EMail: Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA EMail: