If “system emails” means cron, watchdog, or root@hostname mail generated on the mailcow box itself, the linked DKIM Lua thread is only half the story. That guide covers relays. Local system mail usually fails for a simpler reason.
Rspamd signs when the envelope sender’s domain has a key and the message is treated as authenticated or local. Cron and similar jobs typically leave as root@your-hostname. That hostname is rarely a domain you added in mailcow, so there is no matching key and nothing gets signed. After Spamhaus DQS (or any strict path), unsigned mail is more likely to vanish.
Two practical fixes for the on-box case:
Create the hostname as a real domain in mailcow, generate a DKIM key for it, and publish the public key in DNS for that hostname. Then point system mail (aliases, nullmailer, or the panel’s “from” address) at a mailbox on that domain so signing can match.
Or keep a small real mailbox like notify@mail.example.com that already has DKIM, and configure cron/monitoring to send authenticated SMTP through it instead of local pickup as root.
Either way the public TXT has to exist in DNS, not only inside mailcow. Check the next test message’s Authentication-Results: you want dkim=pass on the same domain as the visible From. A pass on some other domain with a From on the hostname still fails DMARC and looks unsigned to filters that care.