Demo
Demo

Knowledge base

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

dkim-expire-after

<domain>

After how long the signature stops being valid
in the configuration this is a linedkim-expire-after neverinside the block <domain>
Signature expiry

Adds a field to the signature with the moment after which it is considered expired. The default is never, no expiry.

Why limit it. A signed message can be saved and sent out again a month later: the signature stays correct, the recipient trusts it. The expiry closes this window — an expired signature is not accepted by the receiver.

The count starts from the signature, not from delivery. A message stuck in a queue longer than the expiry will arrive with an expired signature — and this is the main consideration when choosing the value.

The main trap is an expiry shorter than the message’s life in the queue. bounce-after is four and a half days by default, while the signature expiry is usually set to a day. A message the receiver delayed by two days will arrive with an expired signature — and fail verification through no fault of yours.
What the Hub does. It does not write it — the vendor never stays. An expiry makes sense where a signed message can be reused; for ordinary bulk mail the risk is small, and the price of a wrong value is verification failures on delayed messages.
Recommended values

Count from the message lifetime. The signature expiry should be noticeably longer than bounce-after, otherwise delayed messages will arrive expired.

A day is a common value, but only together with a shortened message lifetime.

The default is left deliberately. The absence of an expiry is not a flaw: for ordinary bulk mail the risk of reuse is small. And dkim-disallow-adding-headers closes a different road — adding headers — and the expiry does not replace it.

The rule to count from the message lifetime is ours. From the manual here: both kinds of value and the default.
Example configuration
# the signature expiry is noticeably longer than the message lifetime
<domain *>
    bounce-after 1d
    dkim-expire-after 3d</domain>
The order of magnitude is exactly this: the message will go to bounce before its signature expires.
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 a term shorter than the message lifetime

our experience

What it costsA message delayed by the receiver arrives with an expired signature and fails verification. The key or the DNS record looks to blame, while the cause is in two lines next to each other.
How to spot itVerification failures only for messages delivered with a delay.
How to do it rightMake the signature expiry noticeably longer than bounce-after.

Setting an expiry instead of protection against tampering

our experience

What it costsThe expiry limits the reuse window but does not prevent adding a second header to the message right now. Tampering is prevented by a different line.
How to spot itAn expiry is set, dkim-disallow-adding-headers is not.
How to do it rightSet both: they close different roads.
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-expire-after <time-interval>
Values
a time interval or the word never — no term
Default
never § 3.3.10.24
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. The count starts from the moment of signing, that is, from sending, not from submission of the message. It is picked up by pmta reload.
⇄

Related directives

1 relation

Does not work without

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

Referenced from

arc-expire-after<domain>The same setting for the ordinary signature. § 3.3.10.34

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 x= field:
pmta show settings gmail.com/vmta1 | grep -i expire-after
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
The x= field in the signature is the expiry moment; without the line it is absent altogether. 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 →