Docker Mailserver
Where is the DKIM selector configured? #4572
-
|
Given that the s=selectror value is critical for DKIM to work and you must create TXT DNS entries with that selector, I find it baffling that I cannot find an answer to that question in the wiki or online after 50mn of research. Previously I was using mailu and the selector was What sets this value and how do we change it? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
replying to my own comment, I search by keyword in a bunch of files and found out: This example file comes from https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/#rspamd and I am ashamed to admit I used it as is, and even tho I modified it thinking I understood, but nope I missed the critical part. how do I modify the page? hoe that helps anyone |
Beta Was this translation helpful? Give feedback.
-
It should default to You can set this to a custom selector instead, so that you could re-use the
So all you would need to do is run this to generate with a custom selector setup config dkim selector dkimBut this would be generating config at This command works the same for both Rspamd and OpenDKIM (verified at least for basic single mail domain use).
I didn't quite follow what you're referring to. I don't see any
What improvement do you want to add? You can click this icon at the top of each docs page to be taken to an edit screen: That will then let you send your changes as a Pull Request to our project. Our docs are written in Markdown format (with some extra syntax understood by the docs generator), so updating the docs is fairly easy :) ReproductionQuick example if it helps: name: example
services:
# We'll send mail from this DMS instance, and it'll use DKIM keys to sign outbound mail:
dms-sender:
image: ghcr.io/docker-mailserver/docker-mailserver:${DMS_RELEASE:-15.1.0}
hostname: mail.example.test
environment:
# If using Rspamd you'd want these two ENV changes:
#ENABLE_RSPAMD: 1
#ENABLE_OPENDKIM: 0
# NOTE: These ENV below are just to simplify the reproduction and aren't relevant to DKIM setup:
ENABLE_AMAVIS: 0
ENABLE_UPDATE_CHECK: 0
# Instead of `volumes` to provide these config files, I'm using the Docker Compose `configs` feature
# so it's all embedded into the single `compose.yaml`:
configs:
- source: dms-accounts
target: /tmp/docker-mailserver/postfix-accounts.cf
# I will need to persist DKIM config generated across a container restart however,
# So I've created a volume for this specifically (normally it'd be included by your standard DMS config mount):
volumes:
- ./opendkim/:/tmp/docker-mailserver/opendkim/
# Or if using Rspamd instead:
#- ./rspamd/:/tmp/docker-mailserver/rspamd/
# DMS (Postfix) will run security checks to verify the sender/recipient domains,
# Add an alias to the container here to leverage Dockers internal DNS, only since
# this reproduction example doesn't have proper DNS records setup:
networks:
default:
aliases:
- example.test
# Mail will arrive to the recipient address of this DMS instance:
dms-receiver:
image: ghcr.io/docker-mailserver/docker-mailserver:${DMS_RELEASE:-15.1.0}
hostname: mail.remote.test
environment:
ENABLE_AMAVIS: 0
ENABLE_UPDATE_CHECK: 0
networks:
default:
aliases:
- remote.test
configs:
- source: dms-accounts-remote
target: /tmp/docker-mailserver/postfix-accounts.cf
# The Docker Compose `configs` feature inlines file content into `compose.yaml`
# NOTE: `$` will be inferred as an ENV on the host to replace with a value if found,
# `$$` is required as an escape to opt-out of that feature when an actual `$` is expected in the file content.
configs:
dms-accounts:
content: |
[email protected]|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.
dms-accounts-remote:
content: |
[email protected]|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.# Generate the DKIM keys for our managed mail domains (example.test), with default `mail` selector:
# NOTE: This won't work for Rspamd, you'll need to instead bring the container up first and then run the command via `docker compose exec dms-sender` after DMS has completed initial setup
$ docker compose run --rm dms-sender setup config dkim
2025-09-22 01:28:56+00:00 INFO open-dkim: Creating DKIM private key '/tmp/docker-mailserver/opendkim/keys/example.test/mail.private'
# Start both DMS container instances (sender + receiver):
$ docker compose up -d --force-recreate
# Now we'll send a test mail from the sender container to the receiver container, this will be signed by DKIM:
$ docker compose exec dms-sender swaks --silent \
--server localhost --port 587 \
--auth PLAIN --auth-user [email protected] --auth-password secret \
--from [email protected] --to [email protected]
# Let's double check that the receiver DMS container got that mail (_which is using OpenDKIM default to verify_):
# (The DKIM selector can be seen as `mail` and that the DNS check failed since proper DNS isn't setup)
$ docker compose logs dms-receiver | grep dkim
dms-receiver-1 | 2025-09-22T01:17:09.011443+00:00 mail opendkim[565]: OpenDKIM Filter v2.11.0 starting (args: -f)
dms-receiver-1 | 2025-09-22T01:17:32.941701+00:00 mail opendkim[565]: DA50A240A44: example-dms-sender-1.my-network [172.16.13.4] not internal
dms-receiver-1 | 2025-09-22T01:17:32.941715+00:00 mail opendkim[565]: DA50A240A44: not authenticated
dms-receiver-1 | 2025-09-22T01:17:32.949301+00:00 mail opendkim[565]: DA50A240A44: key retrieval failed (s=mail, d=example.test): 'mail._domainkey.example.test' record not foundThe mail was delivered though, and we can see it's contents with DKIM verification result marked as failed: $ docker compose exec dms-receiver bash -c 'cat /var/mail/remote.test/jane.doe/new/*'
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail.remote.test
by mail.remote.test with LMTP
id VhTnEyWn0GjfAwAA88HVfQ
(envelope-from <[email protected]>)
for <[email protected]>; Mon, 22 Sep 2025 01:32:21 +0000
Authentication-Results: mail.remote.test; dmarc=none (p=none dis=none) header.from=example.test
Authentication-Results: mail.remote.test;
dkim=fail reason="key not found in DNS" header.d=example.test [email protected] header.a=rsa-sha256 header.s=mail header.b=lAGvhLrw;
dkim-atps=neutral
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=172.16.13.4; helo=mail.example.test; [email protected]; receiver=remote.test
Received: from mail.example.test (example-dms-sender-1.my-network [172.16.13.4])
by mail.remote.test (Postfix) with ESMTP id 1A5E2240A8F
for <[email protected]>; Mon, 22 Sep 2025 01:32:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.test; s=mail;
t=1758504734; bh=ecGWgWCJeWxJFeM0urOVWP+KOlqqvsQYKOpYUP8nk7I=;
h=To:From:Subject;
b=lAGvhLrw52HCOmUYI8giiB2nPgP23dXbu1oLDp9Lts1wiR6stWcotPkkZiM5NPAfV
Nmuxkv+OE9wYXkLTkCUIFRn9G88jPDeEE7P7VbDKbm7ZnzFEhBBBm7oVA81nOGrRYx
SSBIde/W53WnpiA0KZ9o8/fx+PDiy4MerL5nphsxKVcBeP21gThodGlCM5JhZy5Slr
FKs0LKMdEIiAgLq4ykiNEki9Y95w/Hd2hOV0Ms6smyEkvWSa1CGvjceFLfPnOE/PM6
c+6yktTzSUcAb3CkUNrsBstzVKXQTwxLcMIUSSAyoxOE1fy8B/H+8Eq1cUpyG5XokT
DADuQ/y/qdxeA==
Received: from mail.example.test (localhost [IPv6:::1])
(Authenticated sender: [email protected])
by mail.example.test (Postfix) with ESMTPA id 81A3A240A86
for <[email protected]>; Mon, 22 Sep 2025 01:32:14 +0000 (UTC)
Date: Mon, 22 Sep 2025 01:32:14 +0000
To: [email protected]
From: [email protected]
Subject: test Mon, 22 Sep 2025 01:32:14 +0000
X-MS-Reactions: disallow
Message-Id: <[email protected]>
This is a test mailing |
Beta Was this translation helpful? Give feedback.
-
|
thanks but you went way too far lol
Well, for someone coming from baby-sitted solutions like mailcow and mailu, the discovery of the rspamd internals is quite new. So no, "selector" in a random config file is not clear as to what it is. It's indeed the DKIM selector and it's not common lingo for everyone. So yeah I saw the the edit button now that you pointed it out, thanks so much! will do! |
Beta Was this translation helpful? Give feedback.
-
I only brought that up as you seemed to be asking about how to set a custom selector for DKIM so that you could use the existing one you had from Mailu? If you were aware of the
That was not what I meant. You referred to the setting already with
Out of curiousity, how are you finding DMS so far compared to Mailu? Most other solutions have rather dense
Eh, I tend to provide When I write these kind of answers, it's with the community in mind, should another user have the same question as you :) |
Beta Was this translation helpful? Give feedback.
-
|
I see, yes and thanks a lot! Other projects like RedMail/Mailu/Mailcow had large compose because they are designed with kubernetes and scaling in mind. No need to have a container for each service otherwise. For smaller servers like mine, it's way overkill and takes a minute to load. DMS is close to poste.io in that most of the handling is done with scripts and such. In the end it's all about the documentation provided, as the internals of a mail server are no common knowledge. Your wiki is way clearer then poste I think, at least for my needs, that's why I switched to dms and I am glad I did. Certainly biased as I have previous knowledge from other projects, but I can definitely tell when I want to start smth new or not just by looking at the docs. Compared to Mailu, and I did not even enable the clamAV/webdav or all that fluff, pulling emails from outlook mobile is like instant. With mailu it took minutes to get the first imap downloaded. DMS is blazing fast and I love that. Later on I will provide a conversion page for your wiki, so we can have some incentives to pull new users. Importing dovecot mailboxes when messages are gz compressed proved challenging. Also you lose all the INBOX folder subscriptions when you switch, and that's another script to pass with doveadm that I will add in the wiki. All is missing really is a better DNS definitions page guide, and a gui like mailu's admin container. Not spitting in the soup as I used mailu for 5 years, but their admin container has bugs and their "community" is dead and won't help. Once it died, nothing else would work so I had to switch and I'm glad I did. It's once of these cases where a problem and a loss happens, but the door that opens reveals a better future. And the gui does not cover everything anyways, mailu's still provides only the DNS entries to create yourself, they did not implement cloudflare API or anything like that yet. Also upgrading always create problems and you are down reindexing dovecot manually anyways. The gui cannot cover everything or that would be another huge project by itself. What are your thoughts about having a gui? Would you like to assemble a team dedicated to it? I would separate this from dms itself so one does not impede the other. You could say mailu's gui is like that but that's not true, if that container is corrupt, nothing else works. I hope DMS don't fall into this pit too. Don't feel bad about your doc wiki, it's fine as it is. Some stuff missing here and there especially around the DNS part, and I didn't care as I had all in place already except the confusion about the dkim selector. No wiki can be perfect with so many moving parts and user environments. Some want docker, some compose, some kubernetes, and some prefer bare metal, and most don't even use a proxy like nginx or traefik, and some are still using apache. You cannot please everyone. But for users starting from scratch with DMS that may be a challenge. I'll see over time if what I said make sense, maybe I overthink this. All I care about is getting A+ with mail-tester.com and get my emails instantly on weak cellular networks, and that maybe not everyone's dream so I don't judge. |
Beta Was this translation helpful? Give feedback.
-
AFAIK you shouldn't have resource issues with a single image that runs services separately. There are benefits to individual containers for scaling horizontally if there's frequent deployments and bandwidth/storage concerns related to that. One benefit of separate images is the flexibility of versions, since the user has more freedom to version bump/pin there, but that also comes with a disadvantage of upgrades for users when there's breaking changes that require migration or support. I'm not too familiar with how those projects manage that, other than possibly treating their An example with DMS is our next release is slower to push out as we have not only a new base image upgrade (Debian 12 to 13) which sometimes introduces friction to the upgrade process, but the Dovecot package also had a breaking update with 2.3 to 2.4 (not semver) which revamps configuration files syntax quite a bit. There also was no official Rspamd package available (we'd regress in version otherwise), but there was the official Rspamd image with latest Rspamd. One other drawback is although we're using the official Rspamd debian repo, Rspamd doesn't care to provide versioned packages (I've requested it and how to go about supporting that, but they've refused), so we can't pin that version with our I'd usually encourage separate images, far less complex to maintain when the service management is moved up a level to
Agreed! 😁
I really appreciate your feedback given your experience assessing the alternatives out there ❤️ Glad to hear our docs are decent / helpful.
We'd love contributions like that! Looking forward to it ❤️
I would really like to improve our DNS related docs, I do have plans as time allows. The long-term plan is once I've migrated our test suite to leverage Docker Compose instead of just Eventually that may lead to a web UI tool that provides some forms/questions and common deployment use-cases, allowing users to easily generate the A full UI for an actual running container and admin would be a larger commitment that we're presently deferring to community for now to tackle. We are open to an API service that can be run from the DMS image (or as a side-car container) to improve supporting a common interface, and there is a separate repo for that in the organization but no activity for some time pushing that forward.
Yeah, that's something I want to avoid with DMS. There's still legacy contributions that require me to invest time to go back and rewrite features to be done properly. It's rare that anyone else finds time to contribute such since many are niche concerns that only affect a subset of our users, I've often documented these publicly with plenty of insights to resolve, so hopefully our community can at least find the help when they need it 😅
I guess it really depends on what users are doing most often for support requirements. It's one of the benefits of deferring to the community for the time being as it'll better help identify what's important to support should we eventually maintain an official UI. Cloudflare is one of many DNS providers with APIs, my plans for the offline
💯
I would like to tackle it eventually, but all active maintainers are already limited on time and I'm one of the only ones I think confident to review those kind of projects. Our policy for any development tends to be raising a feature request and letting the community express interest in it, then starting with contribution to our docs if possible, followed by official support if maintainers agree. An API service for serving UI projects exists in the org as mentioned. It's mostly exploratory from those that were interested in pursuing it, but they each lost interest/time to proceed. I and another maintainer would strongly prefer Rust and we both have experience with that to maintain such, but last I recall the API contributions were focused on Python (which none of the active DMS maintainers are fond of). It can be simpler to build a UI for the project that takes some shortcuts instead, but I personally prefer starting with that API service as the first step and building from there. There are several community attempts as you're aware of, I've not been following the development of those but if one is trusted enough by the community our docs can endorse it (we can also just mention it with a link). Not quite an official UI but sometimes that's good enough.
If you dig up my past feedback on the topic (focused on an API service), I was in support of a separate repo to maintain it and we could extend the official DMS image (or potentially include it directly if it's a single binary). It would not be concerned with TLS, rate limiting, auth or anything like that. Instead that would be the role of a separate image (or again an image that extends DMS), much like how many web services today delegate these responsibilities through a reverse proxy service when appropriate. This simplifies the maintenance on our end, and provides flexibility to users that want something different than whatever we'd officially do for a web UI admin service. It also allows for different web UIs to be built off it and tailored to the needs of the user/admin, which may be a self-hoster or someone building a SaaS like product with their own additions or features in their web frontend. This internal API service would likely leverage unix sockets for securely sharing access across the two containers, and is something I've done before with Caddy as a Docker API socket proxy. It could manage config files for accounts for example, replacing some of the functionality we already do with bash scripts. I'm happy to migrate the legacy account config files to a more common data format, and with Rust it's simple enough to have both an API service and CLI sharing the same logic for equivalent functionality. The web UI then has it's own frontend and their backend doesn't have to worry too much about the API design outside their own needs.
Yes I'm aware :) That is why we have our maintenance policy for feature requests and typically defer more niche stuff to docs if users want to contribute for the benefit of others coming to DMS after them.
Yeah, that's the core audience that DMS has in mind. I know our docs could do with some more streamlining, but in time it should be a pretty smooth process even for those with little knowledge about setting up mail servers. I think our Users have expressed some difficulty with DNS setup or particular features like relay hosts. I think this will be best served by Cheers for the feedback ❤️ |
Beta Was this translation helpful? Give feedback.
It should default to
mailAFAIK.You can set this to a custom selector instead, so that you could re-use the
dkimselector you already were using in DNS 👍setup dkim config helpwill output:So all you would need to do is run this to generate with a custom selector
dkim:But this would be generating config at
/tmp/docker-mailserver/opendkimfor new DKIM keys (or/tmp/docker-mailserver/rspamdforENABLE_RSPAMD=1+ENABLE_OPENDKIM=0), so if you want to use your own existing one(s) you'd need to modify what was generated there before you restart DMS …