Vulnerability Note VU#268267

DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust

Original Release date: 24 Oct 2012 | Last revised: 15 Mar 2016


DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust when messages are signed using keys that are too weak (< 1024 bits) or that are marked as test keys.


RFC 6376 states "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay, or one of their agents. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message."

1) CWE-347: Improper Verification of Cryptographic Signature: DKIM information is conveyed in an email header called a DKIM-Signature header field. A Signer can indicate that a domain is testing DKIM by setting the DKIM Selector Flag (t=) flag to t=y. Some verifiers accept DKIM messages in testing mode when the messages should be treated as if they were not DKIM signed. From RFC 6376:

t= Flags, represented as a colon-separated list of names (plain-
   text; OPTIONAL, default is no flags set).  Unrecognized flags MUST
   be ignored.  The defined flags are as follows:

   y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
      from Signers in testing mode differently from unsigned email,
      even should the signature fail to verify.

A DKIM-compliant email client, including web-based clients, should not convey any DKIM-related trust to the user about messages in testing mode.

2) CWE-326: Inadequate Encryption Strength: DKIM signing keys with fewer than 1024 bits are weak. From RFC 6376:
Since short RSA keys more easily succumb to off-line attacks,
   Signers MUST use RSA keys of at least 1024 bits for long-lived

The standard lists other factors that influence the choice of key size, implying that 1024-bit keys are not always necessary if the Signer assumes the risk that smaller keys will not be cracked before the message is verified, the signature expires, or the Signer stops using the key. Note that key sizes up to and including RSA-768 have been factored.

The standard does not require Verifiers to reject signatures made by keys with fewer than 1024 bits, however Verifiers may distinguish between e.g. signatures made with 512-bit keys or 1024 bit keys. It may be an important to recipients to know whether or not a DKIM signature could have been spoofed by an attacker who was able to factor a small RSA key.

Furthermore, a number of RSA keys of fewer than 1024 bits are used in production environments. Check the length of DKIM keys and consider using 1024 bit or longer keys, particularly for long-lived keys.

To identify keys with fewer than 1024 bits or test keys users are advised to inspect the server's RSA signing key.


It is possible that an attacker could factor the encryption key for a domain that is using DKIM allowing them to sign emails originating from that domain. An attacker may be able to use a test signing key that is treated as trusted.


System administrators should replace all RSA signing keys fewer that 1024 bits and configure their systems to not use or allow testing mode on production servers.

Users of OpenDKIM are advised to upgrade to 2.6.8 or 2.7.0 and above. The vendor had stated, "In both releases, signatures with key sizes below a configurable limit will be automatically restricted from yielding a "pass" result, and such keys will not be allowed to be used for signature generation. The limit will default to 1024. This applies both to the filter and the library."

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
GoogleAffected22 Aug 201223 Oct 2012
Microsoft CorporationAffected22 Aug 201223 Oct 2012
Yahoo, Inc.Affected22 Aug 201223 Oct 2012
BluehostUnknown-11 Mar 2016
YandexUnknown-15 Mar 2016
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 4.6 AV:N/AC:H/Au:M/C:C/I:N/A:N
Temporal 3.5 E:U/RL:U/RC:UC
Environmental 6.1 CDP:MH/TD:H/CR:ND/IR:ND/AR:ND



Thanks to Zachary Harris for reporting this vulnerability.

This document was written by Michael Orlando.

Other Information

  • CVE IDs: Unknown
  • Date Public: 23 Oct 2012
  • Date First Published: 24 Oct 2012
  • Date Last Updated: 15 Mar 2016
  • Document Revision: 45


If you have feedback, comments, or additional information about this vulnerability, please send us email.