RFC 6376 Internet Standard Authentication

DomainKeys Identified Mail (DKIM) Signatures

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve

Status
Internet Standard. The top of the standards track. An old document can hold this label while the document that replaced it holds a lower one, which is the single most misleading thing about RFC status.
Published
September 2011
Authors
D. Crocker, T. Hansen, M. Kucherawy
Read it
rfc-editor.org · errata · DOI

Replaces RFC 4870: Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys), RFC 4871: DomainKeys Identified Mail (DKIM) Signatures, RFC 5672: RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update.

This document is current and has been amended. 4 later RFCs have changed part of it. Nothing on the RFC itself tells you this.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 125 must, 34 should, 58 may.

2.11 DKIM-Quoted-Printable

  • MAYThe DKIM-Quoted-Printable encoding syntax resembles that described in Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded as an "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (no lowercase characters permitted) representing the hexadecimal-encoded integer value of that character.
  • MUSTAll control characters (those with values < %x20), 8-bit characters (values > %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (";", %x3B) MUST be encoded.
  • MUSTNote that all whitespace, including SPACE, CR, and LF characters, MUST be encoded.
  • MAYAfter encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value, and MUST be removed before decoding.
  • NOT RECOMMENDEDUse of characters not listed as "mail-safe" in [RFC2049] is NOT RECOMMENDED.

3.2 Tag=Value Lists

  • MUST NOTUnencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs.
  • MUSTTags MUST be interpreted in a case-sensitive manner.
  • MUSTValues MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity.
  • MUST NOTTags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid.
  • MUSTWhitespace within a value MUST be retained unless explicitly excluded by the specific tag description.
  • MAYTag=value pairs that represent the default value MAY be included to aid legibility.
  • MUSTUnrecognized tags MUST be ignored.

3.3 Signing and Verification Algorithms

  • MUSTSigners MUST implement and SHOULD sign using rsa-sha256.
  • MUSTVerifiers MUST implement both rsa-sha1 and rsa-sha256.

3.3.1 The rsa-sha1 Signing Algorithm

  • MUST NOTThe hash MUST NOT be truncated or converted into any form other than the native binary form before being signed.
  • SHOULDThe signing algorithm SHOULD use a public exponent of 65537.

3.3.3 Key Sizes

  • MUSTSince short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for long-lived keys.
  • MUSTVerifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys.

3.3.4 Other Algorithms

  • MAYOther algorithms MAY be defined in the future.
  • MUSTVerifiers MUST ignore any signatures using algorithms that they do not implement.

3.4 Canonicalization

  • MAYA Signer MAY specify either algorithm for header or body when signing an email.
  • MUSTVerifiers MUST implement both canonicalization algorithms.
  • MAYFurther canonicalization algorithms MAY be defined in the future; Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms.
  • MUST NOTIt MUST NOT change the transmitted data in any way.

3.4.1 The "simple" Header Canonicalization Algorithm

  • MUSTHeader fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified.
  • MUST NOTIn particular, header field names MUST NOT be case folded and whitespace MUST NOT be changed.

3.4.2 The "relaxed" Header Canonicalization Algorithm

  • MUSTThe "relaxed" header canonicalization algorithm MUST apply the following steps in order:
  • MUSTo Unfold all header field continuation lines as described in [RFC5322]; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by WSP) MUST be interpreted without the CRLF.
  • MUST NOTImplementations MUST NOT remove the CRLF at the end of the header field value.
  • MUSTThe colon separator MUST be retained.

3.4.4 The "relaxed" Body Canonicalization Algorithm

  • MUSTThe "relaxed" body canonicalization algorithm MUST apply the following steps (a) and (b) in order:
  • MUST NOTImplementations MUST NOT remove the CRLF at the end of the line.

3.5 The DKIM-Signature Header Field

  • SHOULDThe DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC5322] and hence SHOULD NOT be reordered and SHOULD be prepended to the message.
  • MUSTThe DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM- Signature header field MUST be treated as though it were an empty string.
  • MUSTUnknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by Verifiers.
  • REQUIREDv= Version (plain-text; REQUIRED).
  • MUSTIt MUST have the value "1" for implementations compliant with this version of DKIM.
  • REQUIREDa= The algorithm used to generate the signature (plain-text; REQUIRED).
  • MUSTVerifiers MUST support "rsa-sha1" and "rsa-sha256"; Signers SHOULD sign using "rsa-sha256".
  • REQUIREDb= The signature data (base64; REQUIRED).
  • MUSTWhitespace is ignored in this value and MUST be ignored when reassembling the original signature.
  • REQUIREDbh= The hash of the canonicalized body part of the message as limited by the "l=" tag (base64; REQUIRED).
  • OPTIONALc= Message canonicalization (plain-text; OPTIONAL, default is "simple/simple").
  • REQUIREDd= The SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED).
  • MUSTThe SDID MUST correspond to a valid DNS name under which the DKIM key record is published.
  • MUSTWhen presented with a signature that does not meet these requirements, Verifiers MUST consider the signature invalid.
  • MUSTInternationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
  • REQUIREDh= Signed header fields (plain-text, but see description; REQUIRED).
  • MUSTThe field MUST contain the complete list of header fields in the order presented to the signing algorithm.
  • MAYThe field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator).
  • MAYThe field MAY contain multiple instances of a header field name, meaning multiple occurrences of the corresponding header field are included in the header hash.
  • MUST NOTThe field MUST NOT include the DKIM-Signature header field that is being created or verified but may include others.
  • MAYFolding whitespace (FWS) MAY be included on either side of the colon separator.
  • MUSTHeader field names MUST be compared against actual header field names in a case-insensitive manner.
  • MUST NOTThis list MUST NOT be empty.
  • OPTIONALi= The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty local-part followed by an "@" followed by the domain from the "d=" tag).
  • MAYThe syntax is a standard email address where the local-part MAY be omitted.
  • MUSTThe domain part of the address MUST be the same as, or a subdomain of, the value of the "d=" tag.
  • MAYNotably, the domain name need not be registered in the DNS -- so it might not resolve in a query -- and the local-part MAY be drawn from a namespace unrelated to any mailbox.
  • MAYThe Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users.
  • SHOULDHowever, the Signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID.
  • OPTIONALl= Body length count (plain-text unsigned decimal integer; OPTIONAL, default is entire body).
  • MUST NOTThis value MUST NOT be larger than the actual number of octets in the canonicalized message body.
  • OPTIONALq= A colon-separated list of query methods used to retrieve the public key (plain-text; OPTIONAL, default is "dns/txt").
  • MUST NOTIf there are multiple query mechanisms listed, the choice of query mechanism MUST NOT change the interpretation of the signature.
  • MUSTImplementations MUST use the recognized query mechanisms in the order presented.
  • MUSTUnrecognized query mechanisms MUST be ignored.
  • MUSTThe only option defined for the "dns" query type is "txt", which MUST be included.
  • MUSTVerifiers and Signers MUST support "dns/txt".
  • REQUIREDs= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED).
  • MUSTInternationalized selector names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
  • RECOMMENDEDt= Signature Timestamp (plain-text unsigned decimal integer; RECOMMENDED, default is an unknown creation time).
  • SHOULDImplementations SHOULD be prepared to handle values up to at least 10^12 (until approximately AD 200,000; this fits into 40 bits).
  • MAYTo avoid denial-of-service attacks, implementations MAY consider any value longer than 12 digits to be infinite.
  • MAYImplementations MAY ignore signatures that have a timestamp in the future.
  • RECOMMENDEDx= Signature Expiration (plain-text unsigned decimal integer; RECOMMENDED, default is no expiration).
  • MAYSignatures MAY be considered invalid if the verification time at the Verifier is past the expiration date.
  • MUSTThe value of the "x=" tag MUST be greater than the value of the "t=" tag if both are present.
  • MAYReceivers MAY add a 'fudge factor' to allow for such possible drift.
  • OPTIONALz= Copied header fields (dkim-quoted-printable, but see description; OPTIONAL, default is null).
  • MAYAfter encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field and MUST be removed before decoding.

3.6.1 Textual Representation

  • MUSTThe following definition MUST be used for any DKIM key represented in an otherwise unstructured textual form.
  • MAYOther tags MAY be present and MUST be ignored by any implementation that does not understand them.
  • RECOMMENDEDv= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1").
  • MUSTIf specified, this tag MUST be set to "DKIM1" (without the quotes).
  • MUSTThis tag MUST be the first tag in the record.
  • MUSTRecords beginning with a "v=" tag with any other value MUST be discarded.
  • OPTIONALh= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms).
  • MUSTUnrecognized algorithms MUST be ignored.
  • OPTIONALk= Key type (plain-text; OPTIONAL, default is "rsa").
  • MUSTSigners and Verifiers MUST support the "rsa" key type.
  • MUST(Note: the "p=" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored.
  • OPTIONALn= Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty).
  • REQUIREDp= Public-key data (base64; REQUIRED).
  • SHOULDVerifiers SHOULD return an error code for any DKIM-Signature header field with a selector referencing a revoked key.
  • OPTIONALs= Service Type (plain-text; OPTIONAL; default is "*").
  • MUSTVerifiers for a given service type MUST ignore this record if the appropriate type is not listed.
  • MUSTUnrecognized service types MUST be ignored.
  • OPTIONALt= Flags, represented as a colon-separated list of names (plain- text; OPTIONAL, default is no flags set).
  • MUSTUnrecognized flags MUST be ignored.
  • MUST NOTVerifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify.
  • MAYVerifiers MAY wish to track testing mode results to assist the Signer.
  • MUSTs Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag.
  • MUST NOTThat is, the "i=" domain MUST NOT be a subdomain of "d=".
  • RECOMMENDEDUse of this flag is RECOMMENDED unless subdomaining is required.

3.6.2 DNS Binding

  • MUSTAll implementations MUST support this binding.

3.6.2.2 Resource Record Types for Key Storage

  • MUSTStrings in a TXT RR MUST be concatenated together before use with no intervening whitespace.
  • MUSTTXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.

3.7 Computing the Message Hashes

  • MUSTThe Signer/Verifier MUST compute two hashes: one over the body of the message and one over the selected header fields of the message.
  • MUSTSigners MUST compute them in the order shown.
  • MAYVerifiers MAY compute them in any order convenient to the Verifier, provided that the result is semantically identical to the semantics that would be the case had they been computed in this order.
  • MUSTIn hash step 1, the Signer/Verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag.
  • MUSTIn hash step 2, the Signer/Verifier MUST pass the following to the hash algorithm in the indicated order.
  • MUSTEach header field MUST be terminated with a single CRLF.
  • MUSTAll tags and their values in the DKIM-Signature header field are included in the cryptographic hash with the sole exception of the value portion of the "b=" (signature) tag, which MUST be treated as the null string.
  • MUSTAll tags MUST be included even if they might not be understood by the Verifier.
  • MUSTThe header field MUST be presented to the hash algorithm after the body of the message rather than with the rest of the header fields and MUST be canonicalized as specified in the "c=" (canonicalization) tag.
  • MUST NOTThe DKIM-Signature header field MUST NOT be included in its own "h=" tag, although other DKIM- Signature header fields MAY be signed (see Section 4).
  • MUSTWhen calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, Signers MUST compute the hash after the encoding.
  • MUSTLikewise, the Verifier MUST incorporate the
  • MUSTHowever, the hash MUST be computed before transport-level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message marker, as specified in [RFC5321]).
  • MAYDKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content.
  • MUSTMessage attachments in MIME format MUST be included in the content that is signed.

3.8 Input Requirements

  • SHOULDTherefore, Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards.

3.9 Output Requirements

  • MUSTFor each signature that verifies successfully or produces a TEMPFAIL result, output of the DKIM algorithm MUST include the set of:
  • MAYThe output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results.

3.10 Signing by Parent Domains

  • MAYIn order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID.
  • MUSTIf the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain.
  • MUSTIf this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.

3.11 Relationship between SDID and AUID

  • MAYDKIM MAY optionally provide a single responsible Agent or User Identifier (AUID).
  • MUSTUpon successfully verifying the signature, a receive-side DKIM Verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.

4.2 Interpretation

  • MAYA Signer MAY sign previously existing DKIM-Signature header fields using the method described in Section 5.4 to sign trace header fields.
  • MAYA Signer MAY add more than one DKIM-Signature header field using different parameters.
  • SHOULD NOTSigners SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified.
  • SHOULDWhen evaluating a message with multiple signatures, a Verifier SHOULD evaluate signatures independently and on their own merits.
  • MAYVerifiers MAY process signatures in any order of their choice; for example, some Verifiers might choose to process signatures corresponding to the From field in the message header before other signatures.
  • SHOULDVerifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the Verifier.
  • MAYTo limit potential denial-of-service attacks, Verifiers MAY limit the total number of signatures they will attempt to verify.
  • SHOULDIf a Verifier module reports signatures whose evaluations produced PERMFAIL results, Identity Assessors SHOULD ignore those signatures (see Section 6.1), acting as though they were not present in the message.

5.3 Normalize the Message to Prevent Transport Conversions

  • SHOULDIn order to minimize the chances of such breakage, Signers SHOULD convert the message to a suitable MIME content-transfer encoding such as quoted-printable or base64 as described in [RFC2045] before signing.
  • SHOULDSuch conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm.
  • MUSTIf the message is submitted to the Signer with any local encoding that will be modified before transmission, that modification to canonical [RFC5322] form MUST be done before signing.
  • MUSTseparator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed.
  • SHOULDAny conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm.
  • MUSTMore generally, the Signer MUST sign the message as it is expected to be received by the Verifier rather than in some local or internal form.

5.3.1 Body Length Limits

  • MAYA body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets.
  • MUSTThe body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count.

5.4 Determine the Header Fields to Sign

  • MUSTThe From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field).
  • SHOULD NOTSigners SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit.
  • MAYSigners MAY include any other header fields present at the time of signing at the discretion of the Signer.
  • MUST NOTThe DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed.
  • MAYSigners MAY claim to have signed header fields that do not exist (that is, Signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message).
  • MUSTWhen computing the signature, the nonexisting header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF).

5.4.1 Recommended Signature Content

  • REQUIREDo From (REQUIRED; see Section 5.4)
  • SHOULDSigners SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk.

5.4.2 Signatures Involving Multiple Instances of a Field

  • MUSTSigners choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block.
  • MUSTSigners wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the "h=" tag of the DKIM-Signature header field and MUST sign such header fields in order from the bottom of the header field block to the top.
  • MAYThe Signer MAY include more instances of a header field name in "h=" than there are actual corresponding header fields so that the signature will not verify if additional header fields of that name are added.

5.5 Compute the Message Hash and Signature

  • MUSTThe Signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm.
  • SHOULDEntities such as mailing list managers that implement DKIM and that modify the message or a header field (for example, inserting unsubscribe information) before retransmitting the message SHOULD check any existing signature on input and MUST make such modifications before re-signing the message.

5.6 Insert the DKIM-Signature Header Field

  • MUSTFinally, the Signer MUST insert the DKIM-Signature header field created in the previous step prior to transmitting the email.
  • MUSTThe DKIM-Signature header field MUST be the same as used to compute the hash as described above, except that the value of the "b=" tag MUST be the appropriately signed hash computed in the previous step, signed using the algorithm specified in the "a=" tag of the DKIM- Signature header field and using the private key corresponding to the selector given in the "s=" tag of the DKIM-Signature header field, as chosen above in Section 5.2.
  • MUSTThe DKIM-Signature header field MUST be inserted before any other DKIM-Signature fields in the header block.

6 Verifier Actions

  • MAYSince a Signer MAY remove or revoke a public key at any time, it is advised that verification occur in a timely manner.
  • MAYA border or intermediate MTA MAY verify the message signature(s).
  • MAYAn MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages.
  • MAYA verifying MTA MAY implement a policy with respect to unverifiable mail, regardless of whether or not it applies the verification header field to signed messages.
  • MUSTVerifiers MUST produce a result that is semantically equivalent to applying the steps listed in Sections 6.1, 6.1.1, and 6.1.2 in order.

6.1 Extract Signatures from the Message

  • MAYThe order in which Verifiers try DKIM-Signature header fields is not defined; Verifiers MAY try signatures in any order they like.
  • MUST NOTVerifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.
  • SHOULD NOTTherefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all.
  • MAYA Verifier MAY limit the number of signatures it tries, in order to avoid denial-of-service attacks (see Section 8.4 for further discussion).
  • MUSTIn the following description, text reading "return status (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") means that the Verifier MUST immediately cease processing that signature.
  • SHOULDThe Verifier SHOULD proceed to the next signature, if one
  • MAYA Verifier MAY either arrange to defer the message for later processing or try another signature; if no good signature is found and any of the signatures resulted in a TEMPFAIL status, the Verifier MAY arrange to defer the message for later processing.
  • SHOULDVerifiers that are prepared to validate multiple signature header fields SHOULD proceed to the next signature header field, if one exists.
  • MAYHowever, Verifiers MAY make note of the fact that an invalid signature was present for consideration at a later step.

6.1.1 Validate the Signature Header Field

  • MUSTImplementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the Verifier to return PERMFAIL (signature syntax error).
  • MUSTVerifiers MUST return PERMFAIL (incompatible version) when presented a DKIM-Signature header field with a "v=" tag that is inconsistent with this specification.
  • MUSTIf any tag listed as "required" in Section 3.5 is omitted from the DKIM-Signature header field, the Verifier MUST ignore the DKIM- Signature header field and return PERMFAIL (signature missing required tag).
  • MUSTIf the DKIM-Signature header field does not contain the "i=" tag, the Verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag.
  • MUSTVerifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag.
  • MUSTIf not, the DKIM-Signature header field MUST be ignored, and the Verifier should return PERMFAIL (domain mismatch).
  • MUSTIf the "h=" tag does not include the From header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed).
  • MAYVerifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired.
  • MAYVerifiers MAY ignore the DKIM-Signature header field if the domain used by the Signer in the "d=" tag is not associated with a valid signing entity.
  • SHOULDThe list of unacceptable domains SHOULD be configurable.
  • MAYVerifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the Verifier views to be essential.

6.1.2 Get the Public Key

  • MUSTThe Verifier MUST validate the key record and MUST ignore any public-key records that are malformed.
  • MUSTWhen validating a message, a Verifier MUST perform the following steps in a manner that is semantically the same as performing them in the order indicated; in some cases, the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged:
  • MAYIf the query for the public key fails to respond, the Verifier MAY seek a later verification attempt by returning TEMPFAIL (key unavailable).
  • MUSTIf the query for the public key fails because the corresponding key record does not exist, the Verifier MUST immediately return PERMFAIL (no key for signature).
  • MUSTIf the result returned from the query does not adhere to the format defined in this specification, the Verifier MUST ignore the key record and return PERMFAIL (key syntax error).
  • MUSTIn particular, the Verifier MUST ignore keys with a version code ("v=" tag) that they do not implement.
  • MUSTIf the "h=" tag exists in the public-key record and the hash algorithm implied by the "a=" tag in the DKIM-Signature header field is not included in the contents of the "h=" tag, the Verifier MUST ignore the key record and return PERMFAIL (inappropriate hash algorithm).
  • MUSTIf the public-key data (the "p=" tag) is empty, then this key has been revoked and the Verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked).
  • MUSTIf the public-key data is not suitable for use with the algorithm and key types defined by the "a=" and "k=" tags in the DKIM- Signature header field, the Verifier MUST immediately return PERMFAIL (inappropriate key algorithm).

6.1.3 Compute the Verification

  • MUSTWhen matching header field names in the "h=" tag against the actual message header field, comparisons MUST be case-insensitive.
  • SHOULDIf the hash does not match, the Verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify).
  • SHOULDIf the signature does not validate, the Verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify).

6.2 Communicate Verification Results

  • SHOULDAny such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block.
  • MAYThe Authentication-Results: header field ([RFC5451]) MAY be used for this purpose.
  • MAYTo circumvent this attack, Verifiers MAY wish to request deletion of existing results header fields after verification and before arranging to add a new header field.

6.3 Interpret Results/Apply Local Policy

  • SHOULD NOTIn general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems.
  • SHOULDIf an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code.
  • MAYWhere the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:
  • SHOULDTemporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code.
  • MUST NOTIn particular, cryptographic signature verification failures MUST NOT provoke 4xx SMTP replies.
  • MUSTOnce the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user.
  • SHOULDIf the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.
  • SHOULDFor diagnostic purposes, the exact reason why the verification fails SHOULD be made available and possibly recorded in the system logs.
  • SHOULDIf the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed.

7 IANA Considerations

  • MUSTAll registrations into these namespaces MUST include the name being registered, the document in which it was registered or updated, and an indication of its current status, which MUST be one of "active" (in current use) or "historic" (no longer in current use).

8.8 Intentionally Malformed Key Records

  • MUSTVerifiers 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

  • MUSTVerifiers 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.14 Inappropriate Signing by Parent Domains

  • MAYNote that a Verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1.

9.2 Informative References

  • MUSTAlthough 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.

Every current email RFC