What domain name should appear in a DKIM signature?

Solution 1:

A DKIM signature from the sender's domain is most reliable, and may be required by the sender's email policies. With the introduction of DMARC it is now possible for domains to publish a policy with desired actions for email which does not meet the policy.

DKIM is intended to match the sender from the header, which may not be the envelope sender. SPF validates the permission of the envelope sender to send mail for the domain using the sending server. DMARC ties the two together, to provide a better policy framework.

All three mechanisms require data to be published in the DNS tree of the domain involved.

DKIM from a third party merely indicates whether or not the signed content has been modified after signing by that domains. This may be useful for repudiation, but not for sender reputation.

Solution 2:

You are looking at the question from the wrong point of view - that of the sender. You should be looking it from the point of view of the receiver.

So let's say we have a [email protected] sending a message to us via mailserver random.com. We know nothing about either domain. Does a signature from foo.com on an email coming from [email protected] tell you anything? Clearly it does, as foo.com is in a position to say something about email accounts it controls. What does a signature from random.com on an email from [email protected] tell you? Very little. random.com could be controlled by a spammer, sending spam that claim to be from [email protected] to get past your filters. So if you know nothing about random.com it's signature also means nothing.

Also, remember permissible for a email to contain multiple DKIM signatures. So if you run a mailing list, a message sent to the list might contain a signature from the domain in the From header. The mailing list might them also sign it, using the list's domain as it appears in the envelope. Both give useful information to the receiver in helping them to decide whether to trust the message.

Solution 3:

In DKIM there is no requirement for the d= value (or the related i= value) to match any other headers in the message. DKIM in itself only authenticates the signer, not the sender, leaving it to the recipient to implement some policy to make this information useful.

DMARC allows the sender domain to specify policies for DKIM, making a DKIM signature much more useful for the recipient. With DMARC the d= and the From: headers must match (either exactly or allowing subdomains, depending on the specified strictness).

For OpenDKIM you will want to look at the SigningTable and KeyTable configuration directives to properly deal with multiple domains.

Solution 4:

DKIM is domain based. It only tells about the signing domain of an email. If you use d=esp.com that is the domain of Email Service Provider, then receiving mail system will use the reputation of esp.com to decide about the email. And if d=customer.com (e.g. domain for From: address) is used then customer.com's reputation score will be used. So if esp.com has high reputation, then it would be wise to use d=esp.com. Otherwise stick with d=customer.com

From RFC 8376 standard:

Once 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. If 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.

SDID : Signing Domain Identifier (=d)

UPDATE:

More on Author based signature vs Third party signature from dkim.org spec:

A signature whose domain does not match the domain of the RFC5322.From address is sometimes referred to as a third party signature. ... Although there is often heated debate about the value of third party signatures...

For some, a signature unrelated to the author domain (the domain in the RFC5322.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 RFC5322.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...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.