Signatures are created by different types of email actors,
based on different criteria, such as where the actor operates
in the sequence from author to recipient, whether they want
different messages to be evaluated under the same reputation
or different, and so on. This section provides some examples of
usage scenarios for DKIM deployments; the selection is not intended
to be exhaustive, but to illustrate a set of key deployment considerations.
The simplest DKIM configuration is to have all mail from a
given organization (Company A) be signed with the same
d= value (e.g. d=companya.example). If there is a desire to
associate a user identity or some other related
information, the i= value can become
uniqueID@companya.example, or uniqueID.companya.example.
In this scenario, Company A need only generate a single
signing key and publish it under their top level domain
(companya.example); the signing module would then tailor the i=
value as needed at signing time.
A slight variation of the one signature case is where
Company A signs all of its mail, but it wants to
differentiate different categories of its outbound mail by
using different identifiers. For example, it might choose
to distinguish marketing mail, billing or transactional
mail, and individual corporate email into
marketing.companya.example, billing.companya.example, and
companya.example, where each category is assigned a unique
subdomain and unique signing keys.
As discussed in , author signatures are a special case of
signatures from an
authors organization where at least one signature on the
message has an i= value that matches the From: address of
the message.
Signers wishing to publish an ADSP record describing their signing practices will
want to include an author signature on their outbound mail to avoid ADSP verification
failures. For example, if the address in the RFC 5322 From is bob@company.example,
the d= value of the author signature would be company.example, and the i= value would be
either company.example or bob@company.example.
An organization may choose to outsource certain key
services to third party companies. For example, Company A
might outsource its benefits management, or Organization B
might outsource its marketing email.
If Company A wants to ensure that all of the mail sent on its behalf
through the benefits providers email servers
shares the Company A reputation, as discussed in
it can either
publish keys designated for the use of the benefits
provider under companyA.example (preferably under a designated
subdomain of companyA.example), or they can delegate a
subdomain (e.g. benefits.companyA.example) to the provider and
enable the provider to generate the keys and manage the
DNS for the designated subdomain.
In both of these cases, mail would be physically going out
of the benefit provider's mail servers with a signature of
e.g. d=benefits.companya.example. Note that the From: address
is not constrained: it could either be affiliated with the
benefits company (e.g. benefits-admin@benefitprovider.example,
or benefits-provider@benefits.companya.example).
Note that in both of the above scenarios, security
concerns dictate that the keys be generated by the
organization that plans to do the signing so that there is
no need to transfer the private key. In other words, the
benefits provider would generate keys for both of the
above scenarios.
Another way to manage the service provider configuration
would be to have the service provider sign the outgoing
mail on behalf of its client Company A with its own
(provider) identifier. For example, an Email Service
Provider (ESP A) might want to share its own mailing
reputation with its clients, and may sign all outgoing
mail from its clients with its own d= domain (e.g. d=espa.example).
Should the ESP want to distinguish among its clients, it
has two options:
and use the i= value to
distinguish among the clients: e.g. a signature on
behalf of client A would have d=espa.example and
i=clienta.espa.example (or i=clienta@espa.example)
so there is a unique
value (and subdomain) for each client: e.g. a
signature on behalf of client A would have
d=clienta.espa.example.
Note that this scenario and the delegation scenario are
not mutually exclusive: in some cases, it may be desirable
to sign the same message with both the ESP and the ESP
client identities.
An ISP (ISP A) might want to assign signatures to outbound
mail from their users according to the users past sending
behavior (reputation). Since the semantics of behavioral
assessments arent allowed as i= values, ISP A
(ispa.example) would have to configure subdomains
corresponding the assessment categories (e.g.
good.ispa.example, neutral.ispa.example,
bad.ispa.example), and use these domains as the d= value
of the signature.
The signing module can also optionally set the i=
value to have a unique user id (distinct from the users
email address local part), for example
user3456@neutral.domain.example. Using a userid that is
distinct from a given email alias is useful in
environments where a single user might register multiple
email aliases.
Note that in this case the i= values are only partially
stable. They are stable in the sense that a given i=
value will always represent the same identity, but they
are unstable in the sense that a given user can migrate
among the assessment subdomains depending on their sending
behavior (i.e., the same user might have multiple i=
values over the lifetime of their account).
In this scenario, ISP A would have to generate as many
keys as there are assessment subdomains (d= values), so
that each assessment subdomain had its own key. The
signing module would then choose its signing key based on
the assessment of the user whose mail was being signed,
and if desired include the user id in the i= tag of the
signature.
Another scenario is that of an agent, usually a re-mailer
of some kind, that signs on behalf of the service or
organization that it represents. Some examples of agents
might be a mailing list manager, or the "forward article
to a friend" service that many online publications offer.
In most of these cases, the signature is asserting that
the message originated with, or was relayed by, the service
asserting responsibility.