A DKIM signature tells the signature verifier that the owner
of a particular domain name accepts some responsibility for
the message. It does not, in and of itself, provide any
information about the trustworthiness or behavior of that
identity. What it does provide is a
verified identity to which such behavioral information can be
associated, so that those who collect and use such information
can be assured that it truly pertains to the identity in
question.
This section lays out a taxonomy of some of the different
identities, or combinations of identities, that might usefully
be represented by a DKIM signature.
Perhaps the simplest case is when an organization signs its own
outbound email using its own domain in the d= tag of the signature. For
example, Company A would sign the outbound mail from its employees
with d=companyA.example.
In the most straightforward configuration, the addresses in the RFC 5322 From
would also be in the companyA.example domain, but that direct correlation is
not required.
A special case of the Single Domain Signature is an Author Signature as
defined by the Author Domain Signing Practices specification.
Author signatures are signatures from an
authors organization that have an i= value that matches the From: address of
the message. Under the
ADSP specification, an i= value matches a RFC 5322 From address when
the domains of the two match exactly, and if the i= value
contains a local part it also matches the local part of
the From: address exactly.
Although an author signature might in some cases be proof against domain
name spoofing the RFC 5322 From address, it is important to note
that the DKIM and ADSP validation apply only to the exact address
string and not to look-alike addresses nor to the
human-friendly "display-name" or names and addresses used
within the body of the message. That is, it protects only
against the misuse of a precise address string within the
RFC5322 From field and nothing else. For example, a
message from bob@domain.example with a valid signature where
i=d0main.example would fail an ADSP check because the
signature domain, however similar, is distinct; however a
message from bob@d0main.example with a valid signature where
i=d0main.example would pass an ADSP check, even though to a
human it might be obvious that d0main.example is likely a
malicious attempt to spoof the domain domain.example. This
example highlights that ADSP, like DKIM, is only able to
validate a signing identifier: it still requires some
external process to attach a meaningful reputation to that
identifier.
Another approach that might be taken by an organization
with multiple active subdomains is to apply the same
(single) signature to mail from all subdomains. In this
case, the signature chosen would usually be the signature
of a parent domain common to all subdomains. For example,
mail from marketing.domain.example,
sales.domain.example, and engineering.domain.example might
all use a signature with d=domain.example.
This approach has the virtue of simplicity, but it is
important to consider the implications of such a choice.
As discussed in ,
if the type of mail sent from the different subdomains is
significantly different or if there is reason to believe
that the reputation of the subdomains would differ, then
it may be a good idea to acknowledge this and provide
distinct signatures for each of the subdomains
(d=marketing.domain.example, sales.domain.example, etc.).
However, if the mail and reputations are likely to be
similar, then the simpler approach of using a single
common parent domain in the signature may work well.
Another approach to distinguishing the streams using a
single DKIM key would be to leverage the i= tag in the DKIM
signature to differentiate the mail streams. For example,
marketing email would be signed with
i=marketing.domain.example and d=domain.example.
It's important to remember, however, that under core DKIM semantics the
i= identifer is opaque to receivers. That means that it will only be an effective
differentiator if there is an out of band agreement about the i= semantics (e.g.,
the semantics specified in ADSP).
A signature whose domain does not match the domain of the
RFC 5322 From address is sometimes referred to as a third party
signature. In certain cases even the parent domain
signature described above would be considered a third
party signature because it would not be an exact match for
the domain in the From: address.
Although there is often heated debate about the value of
third-party signatures, it is important to note that the
DKIM specification attaches no particular significance to
the identity in a DKIM signature. The identity specified
within the signature is the identity that is taking
responsibility for the message, and it is only the
interpretation of a given receiver that gives one identity
more or less significance than another. In particular,
most independent reputation services assign trust based on
the specific identifier string, not its "role": in general
they make no distinction between, for example, an author
signature and a third party signature.
For some, a signature unrelated to the author (identity in
the RFC 5322 From address) is less valuable because there
is an assumption that the presence of an author signature
guarantees that the use of the address in the From: header
is authorized.
For others, that relevance is tied strictly to the
recorded behavioral data assigned to the identity in
question, i.e. its trust assessment or reputation. The
reasoning here is that an identity with a good reputation
is unlikely to maintain that good reputation if it is in
the habit of vouching for messages that are unwanted or
abusive; in fact, doing so will rapidly degrade its
reputation so that future messages will no longer benefit
from it. It is therefore low risk to facilitate the
delivery of messages that contain a valid signature of a
domain with a strong positive reputation, independent of
whether or not that domain is associated with the address
in the RFC5322 From header field of the message.
Third party signatures encompass a wide range of
identities. Some of the more common are:
In cases where email
is outsourced to an Email Service Provider (ESP),
Internet Service Provider (ISP), or other type of
service provider, that service provider may choose
to DKIM sign outbound mail with either its own
identifier -- relying on its own, aggregate
reptutation -- or with a subdomain of the provider
that is unique to the message author but still
part of the provider's aggregate reputation. Such
service providers may also encompass delegated
business functions such as benefit management,
although these will more often be treated as
trusted third party senders (see below).
As discussed above,
organizations choosing to sign for mail
originating from subdomains with a parent domain
signature may also considered to be using 3rd
party signatures in some configurations, depending
on whether or not the "t=s" tag is used to
constrain the parent signature to apply to only
its own specific domain. The default is that a
parent domain signature is considered valid for
its subdomains.
Another possible
category of third party signature would be the
identity of a 3rd party reputation provider. Such
a signature would indicate to receivers that the
message was being vouched for by that 3rd party.
For most of the cases described so far, there has been an
assumption that the identity doing the signing was
responsible for creating and maintaining their own DKIM
signing infrastructure, including their own keys, and
signing with their own identity.
A different model arises when an organization uses a
trusted third party sender for certain key business
functions, but still wants that email to benefit from the
organization's own identity and reputation: in other
words, the mail would come out of the trusted 3rd party's
mail servers, but the signature applied would be that of
the controlling organization.
This can be done by having the 3rd party generate a key pair that is
designated uniquely for use by that trusted 3rd party and publishing
the public key in the controlling organization's DNS
domain, thus enabling the third party to sign mail using the signature
of the controlling organization. For example, if Company A
outsources its employee benefits to a 3rd party, they can
use a special keypair that enables the benefits company
to sign mail as "companyA.example". Because the keypair is
unique to that trusted 3rd party, it is easy for Company A
to revoke the authorization if necessary by simply
removing the public key from the companyA.example DNS.
In this scenario, it is usually a good idea to limit the
specific identities that can be used by even trusted third
parties. The DKIM g= tag enables a key record to specify
one particular From: address local part that must be
specified in the i= tag of the signature: for example,
"g=benefits" would require a signature header tag of
"i=benefits@companyA.example". It is important to note that
although this distinction will be clear to the verifier it
may be invisible to the recipient: there is no constraint
within the DKIM verification process that constrains that
specific i= value to correspond to any of the other
message headers.
A more reliable way of distinguishing the third part mail stream would
be to create a dedicated subdomain (e.g. benefits.companyA.example) and
publish the public key there; the signature would then use d=benefits.companyA.example.
Another possbility for configuring trusted third party
access is to have Company A use DNS delegation and
have the designated subdomain managed directly
by the trusted third party. In this case, Company A
would create a subdomain benefits.companya.example, and
delegate the DNS management of that subdomain to the
benefits company so it could maintain its own key
records. Should revocation become necessary, Company A
could simply remove the DNS delegation record.
A simple configuration for DKIM-signed mail is to have a single
signature on a given message. This works well for domains that
manage and send all of their own email from a single source,
or for cases where multiple email streams exist but each has
its own unique key pair. It also represents the case in which
only one of the participants in an email sequence is able to
sign, no matter whether they represent the author or one of
the operators.
The examples thus far have considered the implications of
using different identities in DKIM signatures, but have
used only one such identity for any given message. In some
cases, it may make sense to have more than one identity
claiming responsiblity for the same message.
One important caveat to the use of multiple signatures is
that there is currently no clear consensus amoung
receivers on how they plan to handle them. The opinions
range from ignoring all but one signature (and the
specification of which of them is verified differs from
receiver to receiver), to verifying all signatures present
and applying a weighted blend of the trust assessments for
those identifiers, to verifying all signatures present and
simply using the identfier that represents the most
positive trust assessment. It is likely that the industry
will evolve to accept multiple signatures using either
option two or three, but it may take some time before that
approach becomes pervasive.
There are a number of situations where applying more than
one DKIM signature to the same message might make sense. A
few examples are:
A company that has multiple
subdomain sending distinct categories of mail
might choose to sign with distinct subdomain
identities to enable each subdomain to manage its
own identity. However, it might also want to
provide a common identity that cuts across all of
the distinct subdomains. For example, Company A
may sign mail for its sales department with a
signature where d=marketing.companya.example, and
a second signature where d=companya.example
Service providers
may, as described above, choose to sign outbound
messages with either their own identity or with an
identity unique to each of their clients (possibly
delegated). However, they may also do both: sign
each outbound message with their own identity as
well as the identity of each individual client.
For example, ESP A might sign mail for their
client Company B with their service provider
signature d=espa.example, and a second
client-specific signature where d= either
companyb.example, or companyb.espa.example. The
existence of the service provider signature could,
for example, help cover a new client while they
establish their own reputation, or help a very
small volume client who might never reach a volume
threshold sufficient to establish an individual
reputation.
Forwarded mail poses a
number of challenges to email authentication. DKIM
is relatively robust in the presence of forwarders
as long as the signature is designed to avoid
message parts that are likely to be modified,
although some forwarders do make modifications
that can invalidate a DKIM signature.
However, some forwarders such as mailing lists or
forward article to a friend services, might choose
to add their own signature to outbound messages to
vouch for it having legitimately originated from
the designated service. In this case, the
signature would be added even in the presence of a
pre-existing signature, and both signatures would
be relevant to the verifier.
Any forwarder that modifies messages in ways that
will break pre-existing DKIM signatures should
always sign its forwarded messages.
Although third
party reputation providers today use a variety of
protocols to communicate their information to
receivers, it is possible that they, or other
organizations willing to put their "seal of
approval" on an email stream might choose to use a
DKIM signature to do it. In nearly all cases, this
"reputation" signature would be in addition to the
author or originator signature.