Demo
Demo

Knowledge base

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

arc-identity

<domain>

On whose behalf forwarding is sealed
in the configuration this is a linearc-identity sender-or-frominside the block <domain>
A difference from the regular signature that is easy to miss

Sets the name on whose behalf the seal is applied. The default is sender-or-from: take it from the Sender header, and if there is none, from From. The values are the same as for dkim-identity, including strict-from.

But it goes into a different field. In the regular signature the given name goes into the signing identity field, and the key domain separately. Here the manual says directly: the name becomes the signing domain, the very one the recipient uses to look up the public key in DNS.

There is one practical consequence: the name set here must have its own DNS record. For the regular signature you could set a name and take the key by domain; here the name and the key domain are one and the same.

The main trap is carrying the value over from the regular signature. The lines are named almost the same and accept the same values, but the result differs: there the name complements the key domain, here it replaces it. A name without a DNS record leaves the seal unverifiable.
What the Hub does. It does not write it: Hub nodes do not forward someone else’s mail. If that appears, the name must be a domain whose record is published by the Hub’s DNS module.
Recommended values

The default works as long as mail of a single domain is forwarded. The name will be taken from the headers, and the key will be found by it too.

Your own domain — when forwarding someone else’s mail. Then the seal is applied on your behalf and verified by your DNS record — exactly as intended for a forwarder.

The name must match the declaration domain of domain-key or be its subdomain. The rule is the same as for the regular signature.

The “name complements versus name replaces” distinction is our reading of two sections side by side. From the manual here come all values, the default and the direct statement that the name goes into the signing domain field.
Example configuration
# we forward someone else's mail and seal it with our domain
domain-key key1, esp123.com, /etc/pmta/key1.esp123.com.pem

<domain *>
    arc-sign yes
    arc-identity @esp123.com</domain>
The recipient will look up the public key by the name key1._domainkey.esp123.com — that is, by the domain set here, not by the domain from 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▶

Carrying the value over from the regular signature

§ 3.3.10.36

What it costsThe lines accept the same values, but here the name becomes the signing domain. A name without its own DNS record leaves the seal unverifiable.
How to spot itThe seal headers are there, but the receiver cannot verify them.
How to do it rightSet a domain whose record is published, and watch that it matches the key declaration.

Keeping the default when forwarding different domains

our experience

What it costsThe name is taken from each message’s headers, so each has its own. You would need a key for every forwarded domain — and you do not have one, these are someone else’s domains.
How to spot itSome forwarded messages have no seal.
How to do it rightSet your own name explicitly — the forwarder seals on its own behalf.
Compatibility
PowerMTA 6.0
described in the manual of this version · linux
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
arc-identity <enumeration-or-address>
Values
a domain or an email address; sender-or-from — take it from the headers; strict-from — only the exact domain from From
Default
sender-or-from § 3.3.10.36
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 sets the signing domain, so it must match the domain-key declaration domain or be its subdomain. It is picked up by pmta reload.
⇄

Related directives

2 relations

Does not work without

arc-sign<domain>Does nothing until forwarding sealing is enabled. § 3.3.10.36

Same name in other blocks

dkim-identity<domain>The same setting for the regular signature — but there the name complements the key domain, while here it replaces it. § 3.3.10.36

How to check on the node
The effective value is printed by the queue settings command; which name the key is looked up by is visible in the seal headers:
pmta show settings gmail.com/vmta1 | grep -i arc-identity
dig +short TXT key1._domainkey.esp123.com
An empty response from the second command means the seal is unverifiable: there is no record for the given name. 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-signcheck-spf-outbounddkim-identitydkim-headersdkim-disallow-adding-headersAll 135 directives of the block →