Creating messages that have one or more DKIM signatures,
requires support in only two outbound email service
components:
A DNS Administrative interface that can create and
maintain the relevant DNS
names &nbhy;&nbhy; including names
with underscores &nbhy;&nbhy; and
resource records (RR).
A trusted module, called the Signing Module, which is
within the organization's outbound email handling
service and which creates and adds the DKIM-Signature:
header field(s) to the message.
If the module creates more than one signature, there
needs to be the appropriate means of telling it which one(s)
to use. If a large number of names is used for signing, it
will help to have the administrative tool support a batch
processing mode.
A receiver attempting to verify a DKIM signature obtains
the public key that is associated with the signature for
that message. The DKIM-Signature: header in the message
contains the d= tag with the basic domain name
doing the signing and serving as output to the Identity
Assessor, and the s= tag with the selector that
is added to the name, for finding the specific public key.
Hence, the relevant
<selector>._domainkey.<domain-name>
DNS record needs to contain a DKIM-related RR that
provides the public key information.
The administrator of the zone containing the relevant
domain name adds this information. Initial DKIM DNS
information is contained within TXT RRs. DNS
administrative software varies considerably in its
abilities to support DKIM names, such as with underscores,
and to add new types of DNS information.
The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain
(ADMD); obvious choices include department-level posting
agents, as well as outbound boundary MTAs to the open
Internet. However any other module, including the author's
MUA, is potentially acceptable, as long as the signature
survives any remaining handling within the ADMD. Hence the
choice among the modules depends upon software
development, administrative overhead, security exposures
and transit handling tradeoffs. One perspective that helps
to resolve this choice is the difference between the
increased flexibility, from placement at (or close to) the
MUA, versus the streamlined administration and operation,
that is more easily obtained by implementing the mechanism
"deeper" into the organization's email infrastructure,
such as at its boundary MTA.
Note the discussion in , concerning use of the
i= tag.
The signing module uses the appropriate private key to
create one or more signatures. The means by which the
signing module obtains the private key(s) is not specified
by DKIM. Given that DKIM is intended for use during email
transit, rather than for long-term storage, it is expected
that keys will be changed regularly. For administrative
convenience, key information should not be hard-coded into
software.
Every organization (ADMD) will have its own policies and
practices for deciding when to sign messages (message
stream) and with what domain name, selector and key.
Examples of particular message streams include all mail
sent from the ADMD, versus mail from particular types of
user accounts, versus mail having particular types of
content. Given this variability, and the likelihood that
signing practices will change over time, it will be useful
to have these decisions represented through run-time
configuration information, rather than being hard-coded
into the signing software.
As noted in , the choice of signing name
granularity requires balancing administrative convenience
and utility for recipients. Too much granularity is higher
administrative overhead and well might attempt to impose
more differential analysis on the recipient than they wish
to support. In such cases, they are likely to use only a
super-name -- right-hand substring -- of the signing name.
When this occurs, the signer will not know what portion is
being used; this then moves DKIM back to the
non-deterministic world of heuristics, rather than the
mechanistic world of signer/recipient collaboration that
DKIM seeks.