Demo
Demo

Knowledge base

PMTA knowledge base›Mechanism§ 10.3.4

A second signature on the same message

second DKIM signature
One message, two signatures

A message can be signed twice, with different keys and under different identities. For this, each signing line has a twin with the second- prefix: second-dkim-sign, second-dkim-identity, second-dkim-headers and so on — twelve of them, a complete set.

What for. Sending on behalf of a client: the first signature is made with the client’s key, by the domain from its From; the second with yours, under your identity. The recipient sees both and can trust either: the client confirms the message is from them, you confirm it went out through you.

The sets are configured independently. In the manual’s example both signatures cover the feedback header for one recipient domain and differ in everything else.

The main trap is that the second lines are not in the manual’s table of contents. Twelve directives are described in a single paragraph in chapter 10 and did not make it into the directive list. They are not in this catalog either: it follows the vendor’s list item for item. Look for them in § 10.3.4, not in the index.
What the Hub does. It does not use it: one signature, with its own key by the sending domain. A second one will be needed if sending on behalf of clients who provide their own keys appears — then the client’s signature will become the first and ours the second.
Example configuration
# the client's signature by its domain and ours by our domain
<virtual-mta 12345>
    domain-key 2017k1, esp.com, /etc/pmta/esp.esp.com.pem
    domain-key 2017-01, customer.com, /etc/pmta/2017-01.customer.com.pem
    <domain *>
        dkim-sign yes
        second-dkim-sign yes        second-dkim-identity @esp.com    </domain>
</virtual-mta>
The first signature will take the key by the domain from From — the client’s; the second by the specified identity — yours. Both declarations must be in place.
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 ends2 mistakes▶

Looking for the second lines in the directive table of contents

§ 10.3.4

What it costsThey are not there: twelve directives are described in a paragraph in chapter 10 and did not make it into the list. Absence from the index is taken for absence of the capability.
How to spot itA search for the name second-dkim-sign finds nothing.
How to do it rightRead § 10.3.4 — all twelve are listed there.

Enabling the second signature without declaring the second key

our experience

What it costsThe key is looked up by the same rules, and if no suitable one is found, the node simply does not add the second signature. Silently: the message goes out with one.
How to spot itThe message has one signature header instead of two.
How to do it rightDeclare a key for the domain set by the second signing identity.
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.
⇄

Related entries

1 relation

Same name in other blocks

How the node signs messages and chooses a keyThe same mechanism a second time, with its own settings. § 10.3.4

How to check on the node
Two signatures are visible in the message as two headers; they differ in the d= and s= fields:
grep -n 'second-dkim' /etc/pmta/config
grep -c 'DKIM-Signature' /var/log/pmta/pmta.log
If the message has one signature header, the second did not work — most often its key was not found. The Hub does not use the second signature.
◇

What else to read

3 articles

◇Do not send what will fail the check at the receiverThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇A message header with which the submitting side adjusts the signatureFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Message signing and authentication