DKIM uses DNS directly for public key distribution rather than a certificate authority infrastructure. This avoids dependency on trusted third parties, requires no new protocols, and allows anyone to validate a signature by querying the signing domain directly.

email, dns, crypto

The body length limit (l= tag) was provided because mailing lists commonly append trailers to messages. This allows a Signer to cover only the original body and allows Verifiers to accept messages with extraneous appended data as a matter of policy, though this introduces security risks described in Section 8.2.

email

The signing identity (SDID/AUID) is not required to match any particular header field such as From. This is intentional because of the broad methods of interpretation by recipient mail systems, and trust binding between the SDID and other identifiers is left to higher-level assessor policy.

email, security

Signing existing DKIM-Signature header fields is legal but inadvisable because intermediaries that do not treat DKIM-Signature as a trace header field may reorder them, breaking such signatures. Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing.

email

All DKIM implementations MUST support the DNS TXT RR binding for key storage. The DKIM key is located at selector._domainkey.domain (e.g., 'foo.bar._domainkey.example.com').

email, dns, crypto

In the DKIM key record, if the 's' flag is present in the t= tag, the domain of the AUID (i=) MUST be exactly the same as the SDID (d=) and MUST NOT be a subdomain. Use of the 's' flag is RECOMMENDED unless subdomaining is required.

email, security

Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST implement both rsa-sha1 and rsa-sha256.

email, crypto, security

Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and MAY validate larger keys.

email, crypto, security

Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name occurs more than once, the entire tag-list is invalid. Tags MUST be interpreted in a case-sensitive manner.

email

The DKIM-Signature header field MUST include the following required tags: v= (version), a= (algorithm), b= (signature data), bh= (body hash), d= (SDID), h= (signed header fields), and s= (selector).

email, crypto

The 'relaxed' header canonicalization algorithm MUST: convert header field names to lowercase, unfold continuation lines, convert WSP sequences to single SP, delete trailing WSP, and delete WSP surrounding the colon separator.

email

The Signer MUST sign the message as it is expected to be received by the Verifier. Bare CR or LF characters MUST be converted to CRLF before signing.

email

The Signer/Verifier MUST compute two hashes: one over the canonicalized body (stored in bh=) and one over the selected header fields including the DKIM-Signature itself (with b= treated as empty string).

email, crypto

Upon 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 AUID (i=) if present.

email, security

Verifiers MUST ignore any signatures using algorithms that they do not implement. Verifiers SHOULD continue checking signatures until one successfully verifies, and MAY limit the total number of signatures they verify.

email, security

Verifiers MUST implement both 'simple' and 'relaxed' canonicalization algorithms. Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms.

email, security

Selectors subdivide the key namespace per signing domain, supporting multiple concurrent public keys. They are encoded as sub-domain labels and form part of the DNS query: selector._domainkey.domain.

email, dns

The DKIM DNS TXT key record uses a tag=value format with tags: v= (version, RECOMMENDED, must be 'DKIM1'), h= (hash algorithms), k= (key type, default 'rsa'), n= (notes), p= (public key data, REQUIRED; empty value means revoked), s= (service type), t= (flags).

email, dns, crypto

The DKIM-Signature header field stores the signature and all key-fetching data as a tag=value list. It SHOULD be treated as a trace header field, SHOULD NOT be reordered, and SHOULD be prepended to the message.

email, crypto

This document creates or updates nine IANA registries: Email Authentication Methods Registry, DKIM-Signature Tag Specifications, DKIM-Signature Query Method Registry, DKIM-Signature Canonicalization Registry, _domainkey DNS TXT Record Tag Specifications, DKIM Key Type Registry, DKIM Hash Algorithms Registry, DKIM Service Types Registry, and DKIM Selector Flags Registry.

email, registry, dns

Attacks involving extra header fields are possible because DKIM signs specific named header fields. An attacker may prepend additional header fields not covered by the signature. Signers SHOULD include all security-relevant header fields and MAY sign non-existent fields to prevent future insertion.

email, security

DKIM does not prevent replay or spam attacks: a valid signed message can be retransmitted to many recipients, since the signature does not bind the message to any specific recipient or envelope information.

email, security

DKIM relies on DNS for public key distribution and is therefore vulnerable to DNS attacks including cache poisoning. DNSSEC can mitigate these risks but is not required by the specification.

email, dns, security

Revoking a key only prevents future verification; messages sent while a key was valid and cached by a Verifier may still appear valid. The gap between key compromise and effective revocation propagation is a fundamental limitation.

email, security, crypto

The l= (body length) tag can be misused: an attacker can append malicious content to a signed message and the signature will still verify for the covered prefix. Signers are discouraged from using l= and Verifiers should treat messages with l= and appended content with suspicion.

email, security

Signature verification ends in one of three states: SUCCESS (successful verification), PERMFAIL (permanent non-recoverable error such as signature verification failure), or TEMPFAIL (temporary recoverable error such as DNS query timeout). The SDID and result MUST be output for SUCCESS and TEMPFAIL.

email, security

DKIM-Quoted-Printable encodes characters as '=' followed by two uppercase hexadecimal digits. All control characters, 8-bit characters, DEL, SPACE, and semicolon MUST be encoded. FWS may be added at arbitrary locations and MUST be removed before decoding.

email

The DKIM-Signature header field tags: v= (version, plain-text, REQUIRED, value '1'), a= (algorithm, plain-text, REQUIRED, e.g. 'rsa-sha256'), b= (signature, base64, REQUIRED), bh= (body hash, base64, REQUIRED), c= (canonicalization, plain-text, OPTIONAL, default 'simple/simple'), d= (SDID, plain-text, REQUIRED), h= (signed headers, plain-text, REQUIRED), i= (AUID, dkim-quoted-printable, OPTIONAL), l= (body length, unsigned decimal, OPTIONAL), q= (query method, OPTIONAL, default 'dns/txt'), s= (selector, plain-text, REQUIRED), t= (timestamp, unsigned decimal, RECOMMENDED), x= (expiration, unsigned decimal, RECOMMENDED), z= (copied headers, OPTIONAL).

email, crypto