Demo
Demo

Knowledge base

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

dkim-identity-fallback

<domain>

A fallback signing name if no key was found for the main one
in the configuration this is a linedkim-identity-fallbackinside the block <domain>
Sign with your own if there is no key of theirs

The usual behavior when no key is found is to send the message without a signature. This line offers a third way: if no key was found for the main signing name, take the fallback name and sign with it.

There is one clear scenario: a mixed stream. Some clients have given you keys for their domains, some have not. For the first, the message is signed with their key; for the second, with yours, instead of going out bare.

It works only together with dkim-identity — the manual says so directly. Without a main signing name, the fallback has nothing to fall back from.

The main trap is the silent substitution of the name. A client set up a key, then changed or deleted the DNS record — and messages in their name start going out signed with your domain. No error, no warning: this is exactly what the line was written for. It can be noticed only by the d= field in sent messages.
What the Hub does. It does not write it: it has no mixed stream with other parties’ keys. The line will be needed if sending on behalf of clients appears, some of whom provide keys and some do not.
Recommended values

Set a domain you have a key for. The fallback name follows the same rule: it must match the domain of some declaration or be its subdomain.

Watch the share. A growing number of messages signed with the fallback name means someone’s keys are no longer being found — a reason to investigate, not to rejoice.

Without dkim-identity the line does not work. This is a requirement of the manual, not a recommendation.

The advice to watch the share is ours. From the manual here come the line’s purpose, the requirement to set the main signing name and the example with a mixed stream.
Example configuration
# the client's key was not found — we sign with our own instead of sending bare
domain-key key1, esp456.com, /etc/pmta/key1.esp456.com.pem

<domain yahoo.com>
    dkim-sign yes
    dkim-identity sender-or-from
    dkim-identity-fallback @esp456.com</domain>
The line above is mandatory: without a set main signing name, the fallback has nothing to fall back from.
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 it without a main signing name

§ 3.3.10.28

What it costsThe line does not work: the manual requires dkim-identity to be set. The fallback looks configured and never fires.
How to spot itMessages without a key still go out unsigned.
How to do it rightSet the main signing name alongside it.

Not watching the share of messages with the fallback name

our experience

What it costsA client deleted the DNS record — and messages in their name quietly switch to your signature. The mismatch between d= and From is visible to the receiver, but not to you.
How to spot itThe share of messages with your domain in d= grows without configuration changes.
How to do it rightCount this share from accounting and investigate when it grows.
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-fallback <address-or-domain>
Values
a domain or email address; requires dkim-identity to be set
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 requires dkim-identity to be set and follows the same rule of matching the domain-key declaration domain. It is picked up by pmta reload.
⇄

Related directives

1 relation

Does not work without

dkim-identity<domain>The main signing name; without it the fallback has nothing to fall back from — this is a requirement of the manual. § 3.3.10.28

Referenced from

arc-identity-fallback<domain>The same for the ordinary signature — but there falling back to your own identity is an exception, while a forwarder never has other people’s keys at all. § 3.3.10.37

How to check on the node
The effective value is printed by the queue settings command; whether the fallback name fired is visible from the signature’s d= field:
pmta show settings yahoo.com/vmta1 | grep -i identity
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
Your domain in the d= field with a client’s From means the fallback name fired: the client’s key was not found. 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 →