The appeal of PhoenixDKIM for an existing DKIM setup is that you can try it with almost no commitment. Your private keys do not change and your DNS records do not change — a DKIM signature only depends on the selector and the key, both of which stay exactly as they are. So a trial is just: stand PhoenixDKIM up on its own milter socket, point it at the keys you already have, and move your MTA over to it. If you like it, leave it; if not, point the milter back. Nothing else moved.
This page covers the two most common starting points. The Rspamd section is only about Rspamd's DKIM signing — PhoenixDKIM does not replace the rest of what Rspamd does.
From OpenDKIM | From Rspamd (DKIM signing)
PhoenixDKIM is a fork of OpenDKIM and keeps its DKIM core, its data-set formats, and nearly all of its configuration keywords. Migrating is mostly a change of binary, config path, and dropping a few keywords for subsystems that no longer exist.
PhoenixDKIM installs a wholly separate footprint and never touches OpenDKIM's files, so the two run side by side. Give PhoenixDKIM its own socket, point it at your existing keys, and move the MTA's milter to it; the signatures it produces validate against your existing DNS because the selector and key are unchanged.
1. Copy the config and keys (or reuse the files in place):
install -d /etc/phoenixdkim cp /etc/opendkim/opendkim.conf /etc/phoenixdkim/phoenixdkim.conf cp /etc/opendkim/KeyTable /etc/opendkim/SigningTable /etc/phoenixdkim/ cp -a /etc/opendkim/keys /etc/phoenixdkim/keys # or point KeyTable at the existing path
Permissions and ownership. PhoenixDKIM runs as its own phoenixdkim user, so it must be able to read the private keys — and by default (RequireSafeKeys) it will refuse a key file that is readable or writable by anyone other than its owner or a group the process belongs to. OpenDKIM's keys are typically owned by the opendkim user, so after copying them (or if you point at the originals in place) give them to phoenixdkim and keep them owner-only:
chown -R phoenixdkim:phoenixdkim /etc/phoenixdkim/keys chmod 600 /etc/phoenixdkim/keys/*.private
A key PhoenixDKIM cannot securely read is skipped rather than used, so check the log on first start if a domain is unexpectedly going unsigned. (Setting RequireSafeKeys false downgrades the refusal to a warning, but fixing ownership is the right answer.)
2. In phoenixdkim.conf, give it a distinct socket and remove any keywords for the dropped subsystems:
Socket local:/run/phoenixdkim/phoenixdkim.sock UserID phoenixdkim:phoenixdkim Mode sv Canonicalization relaxed/relaxed KeyTable /etc/phoenixdkim/KeyTable SigningTable refile:/etc/phoenixdkim/SigningTable
(A single-key setup with Domain / Selector / KeyFile works just as well.)
3. Point the MTA at the new socket. For Postfix:
# was: smtpd_milters = local:/run/opendkim/opendkim.sock smtpd_milters = local:/run/phoenixdkim/phoenixdkim.sock non_smtpd_milters = local:/run/phoenixdkim/phoenixdkim.sock
Reload Postfix and send a test message; the DKIM-Signature uses the same selector and key, so it validates against your existing DNS record. If anything looks off, point the milter back at OpenDKIM — nothing else changed. When you're happy, leave it on PhoenixDKIM and retire OpenDKIM at your leisure.
One caution: run a single signer at a time. Don't chain both OpenDKIM and PhoenixDKIM as signing milters for the same mail, or each message gets two signatures from the same selector.
This section is only about the DKIM signing part of Rspamd — its dkim_signing module. Rspamd is a full mail-filtering system; PhoenixDKIM is a focused DKIM milter and does not replace Rspamd's scanning, scoring, or anything else. The natural split is to keep Rspamd for filtering and let PhoenixDKIM take over just the signing — which it can do while reading the very same key store.
If you manage DKIM keys with rspamadm vault, PhoenixDKIM can sign from the very same secret. Its vault: backend understands the Rspamd layout — a selectors array of {selector, key, alg, valid_start, valid_end} — and applies the identical validity-window rule (valid_start inclusive, valid_end exclusive). During a key roll it behaves exactly as Rspamd does: it signs with every currently-valid selector at once, so the old and new selectors (and RSA + Ed25519) overlap cleanly while DNS propagates.
KeyTable vault://vault.example.com:8200/v1/secret/data/dkim/{d}
SigningTable refile:/etc/phoenixdkim/signingtable
VaultToken hvs.CAES...
No keys are copied and no DNS changes: PhoenixDKIM reads the same store Rspamd already signs from. The full secret format is in the rotation documentation.
Keep Rspamd running for filtering, add PhoenixDKIM as a separate signing milter on its own socket, and turn off Rspamd's signing so you don't double-sign. Keys and DNS stay exactly as they are.
1. Point PhoenixDKIM at your keys — easiest is the shared Vault store above, or a local KeyTable/SigningTable built from the same PEM files — and give it its own socket:
Socket local:/run/phoenixdkim/phoenixdkim.sock
UserID phoenixdkim:phoenixdkim
Mode sv
Canonicalization relaxed/relaxed
KeyTable vault://vault.example.com:8200/v1/secret/data/dkim/{d}
SigningTable refile:/etc/phoenixdkim/signingtable
VaultToken hvs.CAES...
Permissions and ownership. With the shared Vault store the keys themselves live in Vault, but the VaultToken must be reachable by the phoenixdkim user — if you keep it in a file or reuse Rspamd's token, make sure that file is owned by and readable only by phoenixdkim (and that the token's Vault policy allows the read). If instead you sign from local key files exported from Rspamd, the same rule as the OpenDKIM section applies: chown them to phoenixdkim and keep them owner-only, since RequireSafeKeys refuses loosely-permissioned keys by default. Rspamd usually runs as the _rspamd user, so files carried over from it will not be readable by phoenixdkim until you re-own them.
2. Disable Rspamd's signing so only PhoenixDKIM signs. In local.d/dkim_signing.conf:
enabled = false;
3. Add PhoenixDKIM to the MTA's milter chain ahead of Rspamd, so it signs and Rspamd still filters. For Postfix, rspamd_proxy typically listens on localhost:11332:
smtpd_milters = local:/run/phoenixdkim/phoenixdkim.sock, inet:localhost:11332
Reload, send a test message, and confirm the DKIM-Signature validates — same selector, same key, same DNS record. To roll back, re-enable Rspamd's dkim_signing and drop PhoenixDKIM from the milter list. When you're happy, leave signing with PhoenixDKIM and let Rspamd get on with filtering.