Knowledge base
dkim-sign<domain>criticalset by the HubDirectiveTurns signing on for the receiver; the key itself is chosen by the sending domain from the message headers.domain-keyGlobalcriticalDirectiveLinks a selector, a domain and a private key; the first entry whose domain matches or is a parent domain wins.host-nameGlobalcriticalDirectiveThe first name is the main one; which one ends up in the greeting is decided by a five-step resolution.process-x-dkim-key<source>criticalDirectiveA permission for the source: with it, the engine takes the private key straight from the X-DKIM-Key header, signs with it and strips the header; without it, the key travels to the recipient.smtp-source-hostGlobalcriticalDirectiveBinds outgoing connections to a local address or CIDR range and sets the name in the SMTP greeting.check-spf-outbound<domain>DirectiveIf it fails, the message is bounced on our side before it reaches the receiving server; a temporary error means a retry.dkim-identity<domain>DirectiveLets you sign with your own key messages whose From has someone else’s domain — sending on behalf of a client.from-domain<rewrite-list>DirectiveChanges the address domain in the From header — the one the recipient sees; this rule does not touch the envelope.mail-from<rewrite-list>set by the HubDirectiveChanges the address from the SMTP MAIL FROM command — the one a bounce returns to and the one SPF checks; this rule does not touch the From header.arc-identity<domain>DirectiveUnlike the regular signature, the name goes into the domain field — the very one the recipient uses to look up the key.arc-sign<domain>DirectiveEnables three ARC headers; the keys are the same as for the regular signature.dkim-add-body-limit<domain>DirectivePuts the length of the signed part into the signature: an appended footer no longer breaks it — and is no longer noticeable.dkim-disallow-adding-headers<domain>DirectiveThe reverse task: the listed names are put into the signature one extra time, and the appearance of such a header breaks it.dkim-headers<domain>DirectiveThe mandatory list cannot be changed — this line only adds your own to it.dkim-identity-fallback<domain>DirectiveNo key matched the sender’s domain — we sign with our own instead of sending without a signature.domain-key<domain-key-list>DirectiveThe list narrows the key search to itself — and is chosen by a message header, not by the configuration.process-x-dkim-options<source>DirectiveA permission for the source: with it the header sets the selector, domain, identity and query method for signing one message; without it the header is ignored and stays in the message.arc-algorithm<domain>DirectiveThere is exactly one value; the line exists for completeness of the set, not for choice.arc-body-canon<domain>DirectiveThe only ARC canonicalization line where there really is a choice.arc-expire-after<domain>DirectiveThe default is never; a forwarder’s window for reuse is especially large.arc-headers<domain>DirectiveThe mandatory set is the same as for the ordinary signature; the line only adds to it.arc-headers-canon<domain>DirectiveExactly one method is supported; unlike the ordinary signature, there is no choice.arc-identity-fallback<domain>DirectiveFor a forwarder this is not a fallback but the main path: it never has other people’s keys.arc-oversigned-headers<domain>DirectiveThe same protection against substitution as with the ordinary signature; there is no default, and without the line it does not act.dkim-add-timestamp<domain>DirectiveOne field by which you can later tell when the message was signed.dkim-algorithm<domain>DirectiveThe default is right; the second value is obsolete and no longer accepted by receivers.dkim-body-canon<domain>Directiverelaxed forgives extra spaces in lines, simple does not; empty lines at the end of the body do not count under either.dkim-expire-after<domain>DirectiveThe default is never; an expiry is set where reuse of a signed message is feared.dkim-headers-canon<domain>Directiverelaxed forgives spaces and the case of names, simple forgives nothing.dkim-query-method<domain>DirectiveThere is exactly one lookup method, and it is implied by default; the line exists for compatibility.How the node signs messages and chooses a keycriticalMechanismThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.Do not send what will fail the check at the receivercriticalMechanismThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.A second signature on the same messageMechanismTwelve lines with the second- prefix: the message is signed twice, with different keys and under different identities.What is not allowed in FIPS modeMechanismIn FIPS mode only a validated set of algorithms is available: some familiar encryption and signing settings become unavailable.A signing key that came along with the messageMechanismA private key is passed in a message header; the node signs with it and removes the header before sending.A message header with which the submitting side adjusts the signatureMechanismFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.A signature that preserves someone else's verification when forwardingMechanismThree headers in which the forwarder attests: the message came to me like this and with these verification results.Authentication directive indexMechanismA summary of the directives related to login: they are scattered across several blocks.How to enable DKIM signing from scratchcriticalProcedureEight steps: domain, selector, key, permissions, DNS record, declaration, enabling and routing.Change a signing key without interrupting sendingProcedureAdd the new key under a new selector, apply, start signing with it, wait for messages with the old one to leave — and only then remove the old one.<domain-key-list>Configuration blockA named list of domain-key lines at node level: a message selects it with the x-dkim-options header with key-list=, and the key is searched only in that list.check spfCommandReturns the same verdict as the recipient — based on the address, the greeting name and the return address.