Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.27

dkim-identity

<domain>

In whose name the signature is made
in the configuration this is a linedkim-identity sender-or-frominside the block <domain>
Whose name is in the signature when sending on someone else’s behalf

A signature has two name fields. d= is the key domain, taken from the domain-key declaration. i= is the signing identity, and it is set by this line. By default the node takes it from the Sender header, or from From if there is none.

Why it gets touched. Sending on behalf of a client: From has the client’s domain, but you have no key for that domain — the client controls it. By setting your own domain as the signing identity, you sign the message with your own key and your own DNS record, while From stays the client’s.

There is one restriction, and it is strict. The signing identity must match the key domain or be its subdomain. You can sign with your own domain, not with someone else’s.

The separate strict-from value requires an exact match of the domain from From: neither subdomains nor the Sender header take part in the key search anymore.

The main trap is that a signature in your own name is visible to the recipient. A message from the client will carry your domain in the d= field. Large receiving servers compare it with From, and the mismatch by itself lowers trust: the message is signed by someone other than the sender. It is better to agree on a key on the client’s domain and keep this line as a fallback.
What the Hub does. It does not write it — the vendor behavior remains: the signing identity is taken from the message headers. Sending on behalf of a client with someone else’s From is not provided for in the Hub; if it appears, this line will be needed together with a record in your own DNS.
Recommended values

The default is almost always right. A signing identity from the headers is what the receiving server expects.

Your own domain — only when there is no key for the other one. And understanding the cost: the mismatch of d= with From is noticeable to the recipient.

strict-from narrows the key search. It is useful where subdomains must not be signed with the parent key — but it will also silently leave unsigned everything that did not match exactly.

The assessment “a signature in your own name lowers trust” is ours. From the manual here are all the values, the link between the signing identity and the key domain, the restriction on their match and the behavior of the strict mode.
Example configuration
# sending on behalf of a client: From has the client's domain, the signature is ours
domain-key key1, esp456.com, /etc/pmta/key1.esp456.com.pem

<domain yahoo.com>
    dkim-sign yes
    dkim-identity @esp456.com</domain>
The signing identity matches the key domain — otherwise the declaration will not fit. In the message the recipient will see the client’s From and your domain in the d= field.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Setting a signing identity that does not match the key domain

§ 3.3.10.27

What it costsThe declaration does not fit, and the message leaves unsigned — silently. The signing identity must match the key domain or be its subdomain.
How to spot itSigning is on, the key exists, but messages have no header.
How to do it rightBring the signing identity in line with the domain-key declaration’s domain, or create a key for the needed domain.

Signing all mail on behalf of clients in your own name

our experience

What it costsEvery message has d= of your domain with the client’s From. Large receiving servers check this, and trust in the messages drops — even though the signature is formally valid.
How to spot itDeliverability for client domains is lower than for your own, with a valid signature.
How to do it rightAgree on a key on the client’s domain; keep this line as a fallback.

Setting strict-from without checking subdomains

§ 3.3.10.27

What it costsThe key search narrows to the exact domain from From. Everything leaving from subdomains stays unsigned, even though a parent key exists.
How to spot itMessages from the main domain are signed, those from subdomains are not.
How to do it rightEither create keys for the subdomains or return to the regular value.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
dkim-identity <enumeration-or-address>
Values
a domain or an email address; sender-or-from — take it from the headers; strict-from — only the exact domain from From
Default
sender-or-from § 3.3.10.27
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It sets the signature’s i= field, not d=: that one is taken from the domain-key declaration’s domain, and the signing identity must match it or be its subdomain. It is picked up by pmta reload.
⇄

Related directives

2 relations

Depends on

domain-keyGlobalThe declaration’s domain is the signing domain; the signing identity must match it or be its subdomain. § 3.3.10.27

Works together with

dkim-identity-fallback<domain>A fallback signing identity for when no key was found for the main one; it does not work without this line. § 3.3.10.28

Referenced from

dkim-sign<domain>Decides on whose behalf the signature is made — and the key is chosen by that same name. § 3.3.10.27arc-identity<domain>The same setting for the regular signature — but there the name complements the key domain, while here it replaces it. § 3.3.10.36

How to check on the node
The queue settings command prints the effective value; what came out is visible in the i= and d= fields of the signature itself:
pmta show settings yahoo.com/vmta1 | grep -i dkim-identity
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
A mismatch of d= with the domain from From is exactly what the receiving server sees and checks. The Hub does not write this line.
◇

What else to read

3 articles

◇A license for a fleet, not for a serverThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.◇How the node selects a source and combines its settingsA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.◇Address lists — named and unnamedA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Message signing and authentication · Sender isolation
Neighboring settings of the block <domain>:dkim-signcheck-spf-outboundarc-signdkim-disallow-adding-headersdkim-add-body-limitAll 135 directives of the block →