When adding DKIM keys through the aanagement UI for a secondary local domain, the UI accepts the operation without error but no DNS TXT records are produced and no keys are stored in the database. Outbound mail from the affected domain is unsigned. DKIM works correctly on the primary domain, confirming this is specific to secondary domain key generation. Build errors only surface in the web UI — nothing is written to the Stalwart log file or Docker stdout, making the failure completely silent from an operator perspective.
Expected Behavior
Each saved DKIM key should generate a DNS TXT record to publish, and Stalwart should sign outbound mail from that domain using the stored private key.
Actual Behavior
No DNS TXT record appears after saving. No error is shown in the UI. Outbound mail is unsigned. Attempting to use the keys later produces UI-level errors but nothing in the server logs.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
using linode API
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Since DKIM key generation and DNS record publication are two separate steps under the hood, this can look like a total silent failure if either step isn’t wired up correctly for the secondary domain. A few things worth checking before assuming it’s a server bug:
DNS publication is per-Domain, not inherited from the primary domain. Automatic DNS management (dnsManagement) is a field on each individual Domain object, including dnsServerId (which DnsServer/API credentials to use) and publishRecords (which record types, dkim must be included). Even if your primary domain has this configured, a secondary domain does not automatically inherit it — it needs dnsManagement set to Automatic with its own dnsServerId pointing at your Linode DnsServer object. See DNS records.
Publication is asynchronous via a Task, and failures land there, not in the server log. When automatic DNS management is enabled/triggered on a domain, Stalwart schedules a DnsManagement Task. If the Linode API call fails (bad token, wrong zone/origin, permissions, etc.) the Task is marked Failed and the reason is in its failureReason field, visible under Management > Tasks in the WebUI. This is the place to look for the actual error, since it will not appear in the Docker/server log.
DKIM key/signature storage is separate from DNS publication. A DkimSignature object requires a valid domainId pointing at the secondary Domain’s own ID. If that ID is wrong or the domain wasn’t fully created first, the signature save can silently no-op in the UI. Double-check the DkimSignature record actually exists under Domains > DKIM Signatures for the secondary domain and that its domainId matches the secondary domain, not the primary.
If you’ve verified dnsManagement is Automatic on the secondary domain with a valid dnsServerId/publishRecords including dkim, and there’s still no Task created or no DkimSignature object saved at all (not even a failed Task), that points to a genuine bug rather than a config gap — a human maintainer will need to look at that with your exact setup.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
When the DKIM or DNS step fails, the task records why. Saving a key queues a DkimManagement task, publishing queues a DnsManagement task, and a failure in either shows up in the task list in the web UI and in the log as task-manager.task-failed at warning level. What do those two tasks say for the secondary domain?
Publishing also depends on how that domain is set up. Its DNS management has to be Automatic with DKIM among the records it publishes; otherwise the keys are created but the TXT records have to be added by hand from the domain’s DNS records view. Switching management to Automatic is what queues the tasks. With Linode, the secondary domain’s zone also has to live in the same Linode account as the API token, or the task fails with “Linode domain … not found”. DNS Providers | Stalwart covers the provider setup.