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.access-token<vault>DirectiveThe Vault authorization token; created manually on the vault side and needed by almost everything that works through the vault.cache-ttl<vault>DirectiveThe time after which a key obtained from Vault is requested again; a missing key is always cached for an hour, regardless of this line.server-url<vault>DirectiveThe name or address of the Vault server and, if needed, a port; the scheme is http or https.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.Secrets in an external vaultMechanismSigning keys can be kept in HashiCorp Vault: the configuration keeps a path, and the engine fetches the key over HTTP and keeps it in memory without writing it to disk.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.<vault>Configuration blockThe block describes the connection to Vault; from there the node takes signing keys, certificates and their passwords without keeping them in its files.clear dnscacheCommandRemoves all records of a domain from the engine’s DNS cache; with a star, the whole cache.clear secretscacheCommandClears the secrets cache; on the next access they are requested from the store again.