Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.19

check-dkim-inbound

<source>

Whether to verify the signature on messages submitted to us
in the configuration this is a linecheck-dkim-inbound falseinside the block <source>
A check that has no refusals

Enables DKIM signature verification on incoming messages. If a message carries a signature header, the node verifies it and writes the result into the same header as the other entry checks.

The difference from SPF and the return address check is fundamental: there are no refusals here. Those have three reject-* lines each, this one has none. The engine can only check and record; the decision about what to do with the message rests with whoever reads the header further down the chain.

Not every message has something to check. Without a signature header the check is not performed at all — there will be no result, and that is not the same as a failed check.

The main trap is expecting messages with an invalid signature to stop arriving. They will not: the engine cannot reject based on this result. The check provides a marker, and that is all; it has to be handled by whatever stands after the node.
What the Hub does. It does not write it: nodes accept mail only from the Hub itself, and there is no reason to verify its signature. The line will be needed if a node starts accepting mail from outside — for example, reports and complaints.
Recommended values

It is safe to enable. There are no refusals based on the result, and acceptance of the message does not change with any outcome.

It is most useful for report intake. Complaints and reports come from mailbox providers and are usually signed; the check separates real ones from forged ones.

Someone has to read the result. Without a processor that looks at the header, enabling it achieves nothing.

The advice about report intake is ours. From the manual here come the default, the addition of a header with the result and the condition “if the message has a signature header.”
Example configuration
# we accept reports from outside — separating real ones from forged ones
<source 0/0>
    check-dkim-inbound true    check-arc-inbound true
</source>
Neither of the two lines has refusals: both only record the result in the header of the accepted message.
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▶

Expecting messages with an invalid signature to stop arriving

our experience

What it costsThe engine cannot reject based on this check’s result — it has no refusal lines. All messages arrive; only the header contents change.
How to spot itThe check is enabled, but the flow of suspicious messages is the same.
How to do it rightHandle the result in whatever stands after the node.

Confusing a missing signature with an invalid one

our experience

What it costsFor a message without a signature header the check is not performed at all. Treating such a message as having failed the check means punishing it for something the sender did not do.
How to spot itThe processor classifies unsigned messages as forgeries.
How to do it rightDistinguish three states: no signature, a valid signature, an invalid signature.
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
check-dkim-inbound <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.7.19
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is set in a <source> block and applies to mail submitted by a matching source; with several matching blocks the most precise one wins. This check has no paired refusal lines — unlike the SPF and return address checks. It is picked up by pmta reload.
⇄

Related directives

2 relations

Works together with

Two inbound report processors and what to do with themThe check result goes to the processor together with the message — the engine cannot reject a message here. § 3.3.7.19

Often used with

check-spf-inbound<source>A neighboring check of incoming mail: its result goes into the same header. § 3.3.7.19

Referenced from

trace-dkim-check<source>The line does not trigger until signature verification is enabled. § 3.3.7.20

How to check on the node
The value is set in the source configuration; the result is visible in the header of the accepted message:
grep -n check-dkim-inbound /etc/pmta/config
grep -i 'Authentication-Results' /var/log/pmta/pmta.log | tail -3
No mention of a signature in the header means the message did not have one — which is not the same as a failed check. The Hub does not write this line.
◇

What else to read

3 articles

◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇The group that grants management rightsMembership in the pmta group gives an unprivileged user the right to call the node’s commands and use submission.◇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.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Receiving inbound mail · Node security
Neighboring settings of the block <source>:reject-spf-check-permerrorcheck-spf-inboundreject-spf-check-failreject-spf-check-temperrorprocess-x-dkim-optionsAll 74 directives of the block →