Demo
Demo

Knowledge base

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

dkim-query-method

<domain>

How the recipient should look up the public key
in the configuration this is a linedkim-query-methodinside the block <domain>
A field with no second value

Sets the signature field by which the sender says how to look up the public key. In practice there is one method: a TXT record in the Domain Name System.

It is implied even without the line. The standard names a DNS query as the default method, and receivers look up the key exactly that way whether the field is set or not.

The line remains for the completeness of the signature and for compatibility with old verifiers that expected to see the field explicitly.

The main trap is inventing a value. The field accepts an arbitrary string, and nobody on your side checks it for typos. A receiver that meets an unknown lookup method may fail to find the key at all — and the signature will fail with everything else configured perfectly.
What the Hub does. It does not write it — and rightly so: the field is optional, and there is only one lookup method anyway. The line adds an extra byte to the signature and a chance for a typo.
Recommended values

Do not set it. The method is implied, the field is optional.

If you do set it — only dns/txt. No other methods are in use.

Check the value by eye. The engine does not validate it: whatever you write goes into the signature.

The advice not to set it is ours. From the manual here: only the purpose of the line and its syntax — an arbitrary string.
Example configuration
# the line is optional; if you set it, set exactly this
<domain *>
    dkim-query-method dns/txt</domain>
There is one key lookup method and it is implied by default: without this line the receiver looks up the DNS record in exactly the same way.
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▶

Setting an arbitrary value

our experience

What it costsThe engine accepts any string and puts it into the signature as is. A receiver that does not recognize the lookup method may fail to find the key — with a correct key and a correct DNS record.
How to spot itVerification failures with everything else configured perfectly.
How to do it rightRemove the line or set dns/txt.

Expecting the line to speed something up

our experience

What it costsThe field only states the method the recipient would use anyway. It has no effect on the speed or reliability of the key lookup.
How to spot itThe line is set in the hope of faster verification.
How to do it rightNothing: the field is informational.
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-query-method <string>
Values
a string with the key lookup method; in practice the only meaningful value is dns/txt
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.25

How to check on the node
The value is printed by the queue settings command; what came out is visible in the signature’s q= field:
pmta show settings gmail.com/vmta1 | grep -i query-method
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
Without the line there is no q= field in the signature at all — and that is normal. 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 →