Demo
Demo

Knowledge base

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

dkim-algorithm

<domain>

Which algorithm the signature is computed with
in the configuration this is a linedkim-algorithm rsa-sha256inside the block <domain>
A choice that no longer exists

Sets the signature algorithm. There are two values: rsa-sha256 — the default, and rsa-sha1 — a historical one.

There is nothing to choose here. The sha1 hash function is recognized as unfit for signatures: practical collisions have been demonstrated for it, and mail standards have forbidden it in DKIM. Large receivers either do not verify such a signature at all or consider it invalid.

The line remains for compatibility with old configurations. It should not be in a new one.

The main trap is carrying the line over from an old config. The value rsa-sha1 in an inherited configuration looks harmless and moves along with the other lines. Messages are then signed as if there were no signature: the receiver does not accept it, while in your configuration everything is “set up”.
What the Hub does. It does not write it — the vendor rsa-sha256 stays. It is the only usable value, and there is no reason to touch it.
Recommended values

Leave the default. There is no other usable value.

Check inherited configurations. A line with rsa-sha1 moves over silently and devalues the signature.

Key length matters more than the algorithm. Keys shorter than 1024 bits are already rejected by some receivers; when generating, take 2048.

The remark about key length and the advice to check inherited configurations are ours. From the manual here: both values and the default.
Example configuration
# the line should not be here; it is shown because it gets removed
<domain *>
    dkim-algorithm rsa-sha256</domain>
The value matches the default — the line is here only so that it is not confused with an inherited rsa-sha1.
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▶

Carrying rsa-sha1 over from an old configuration

our experience

What it costsThe signature is computed with an obsolete algorithm and is not accepted by receivers. Formally it exists, in fact it does not — and in the configuration everything looks set up.
How to spot itThe signature’s a= field contains rsa-sha1.
How to do it rightRemove the line — the default is right.

Changing the algorithm while investigating verification failures

our experience

What it costsThe cause of failures is almost never the algorithm: more often the key, the header set or the DNS record is to blame. Changing the algorithm changes the signature without removing the cause.
How to spot itThe value was changed, the failure rate is the same.
How to do it rightLook at the signature’s d=, s= and h= fields and at the DNS record.
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-algorithm <enumeration>
Values
rsa-sha256 or rsa-sha1; the second value is historical and not accepted by receivers
Default
rsa-sha256 § 3.3.10.21
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 is merged across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload; for queued messages it applies from the next attempt.
⇄

Related directives

1 relation

Does not work without

dkim-sign<domain>Does nothing until signing is enabled. § 3.3.10.21

Referenced from

arc-algorithm<domain>The same setting for the ordinary signature — there it has two values, and the second is obsolete. § 3.3.10.31

How to check on the node
The effective value is printed by the queue settings command; what came out is visible in the signature’s a= field:
pmta show settings gmail.com/vmta1 | grep -i dkim-algorithm
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
An a= field with the value rsa-sha1 in the signature means that for most receivers the messages effectively go out unsigned. The Hub does not write this line.
◇

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
Neighboring settings of the block <domain>:dkim-signdkim-identitycheck-spf-outbounddkim-disallow-adding-headersdkim-add-body-limitAll 135 directives of the block →