Docker Mailserver Multi-Domain Setup Without Breaking Existing Mail

If you already have Docker Mailserver working for one domain, adding a second domain can feel riskier than the first setup. The danger is not that Docker Mailserver cannot host multiple domains. It can. The danger is accidentally changing the identity that the rest of the world already trusts.

This is the checklist I use for adding a new mail domain to an existing VPS mail server while preserving the existing mailboxes, reverse DNS, TLS certificate, DKIM signing, and app SMTP settings.

Goal: add another domain without changing the server identity that is already delivering mail.

The mental model

A mail server can receive and send mail for many domains while presenting one stable server hostname to the world.

One VPS mail identity
  ├─ mail.primary-domain.example
  │   ├─ PTR/rDNS points here
  │   ├─ SMTP announces this hostname
  │   └─ TLS certificate covers this hostname
  │
  ├─ [email protected]
  └─ [email protected]

The second domain does not need its own PTR record. In most VPS setups you only get one reverse DNS value for the server IP anyway. The important thing is that the PTR, forward DNS, SMTP banner, and certificate all agree on the mail server hostname.

What not to change

Before touching the new domain, write down what already works and avoid changing it unless you have a specific reason.

• Do not change the existing PTR/rDNS just because a new domain is being added.
• Do not rename the Docker Mailserver hostname if existing deliverability is good.
• Do not delete or regenerate existing DKIM keys for the first domain.
• Do not replace the existing Rspamd DKIM config without checking how it signs the current domain.
• Do not change app SMTP environment variables that already work for production apps.

DNS records for the new domain

The new domain needs its own MX, SPF, DKIM, and DMARC records. The MX points to the existing mail hostname.

second-domain.example.      MX   10 mail.primary-domain.example.

For SPF, the simplest safe form is often to authorize the domain's configured MX host:

second-domain.example.      TXT  "v=spf1 mx -all"

That avoids publishing a raw server IP in docs or blog posts. Use the exact SPF policy that matches your real mail flow, but keep it simple unless you actually send through more providers.

Start DMARC in monitoring mode while you verify delivery:

_dmarc.second-domain.example. TXT "v=DMARC1; p=none; adkim=s; aspf=s"

Then publish the DKIM record generated for the new domain. With the common mail selector, it looks like this:

mail._domainkey.second-domain.example. TXT "v=DKIM1; k=rsa; p=..."

The p=... value must be the exact public key produced by Docker Mailserver. Do not paste labels like “Name”, “Type”, or “Value” into the DNS value field.

Add the mailbox

Docker Mailserver's setup command can add the mailbox without changing the existing domain.

docker exec mailserver setup email add [email protected]

Use a strong password and store it in your local secret manager. Do not commit it to the app repository, blog repository, Docker Compose file, or public documentation.

Then verify the mailbox exists:

docker exec mailserver setup email list

Generate DKIM for the new domain

Generate DKIM for the added domain:

docker exec mailserver setup config dkim domain second-domain.example

Now check how DKIM signing is configured. This is the part that trips people up. If your mail server already has a custom Rspamd DKIM signing file, generating a new key may not automatically add the new domain to the signing map.

The config needs both domains, not only the newest one:

domain {
  primary-domain.example {
    selector = "mail";
    path = "/tmp/docker-mailserver/rspamd/dkim/...primary-domain.example.private.txt";
  }

  second-domain.example {
    selector = "mail";
    path = "/tmp/docker-mailserver/rspamd/dkim/...second-domain.example.private.txt";
  }
}

Preserve the existing domain block. Add the new block beside it.

Keep TLS focused on the mail hostname

The mail client connects to the server hostname, not to every mailbox domain. That means a single certificate for the mail hostname is normally enough:

mail.primary-domain.example

If your VPS already runs web apps through a reverse proxy, DNS-01 validation is often the cleanest way to issue or renew the mail certificate because it does not need to take over ports 80 or 443.

Verification checklist

After DNS has propagated and the mail container has been restarted if needed, verify each layer directly.

1. MX for the new domain points at the existing mail hostname.
2. The mail hostname resolves to the VPS.
3. PTR/rDNS still points to the stable mail hostname.
4. SPF exists for the new domain.
5. DKIM TXT exists for the new domain and exactly matches the generated public key.
6. DMARC exists for the new domain.
7. The mailbox authenticates over IMAP.
8. SMTP submission accepts the mailbox credentials.
9. A test message from the new domain arrives in the inbox.
10. A reply from the new domain signs with DKIM and passes SPF/DMARC alignment.

Useful commands

These are generic examples. Replace the domains and container name with your own.

# Check MX
 dig +short MX second-domain.example

# Check SPF
 dig +short TXT second-domain.example

# Check DMARC
 dig +short TXT _dmarc.second-domain.example

# Check DKIM
 dig +short TXT mail._domainkey.second-domain.example

# Check the presented IMAP certificate
 openssl s_client -connect mail.primary-domain.example:993 \
   -servername mail.primary-domain.example -verify_return_error

Common failure modes

• Changing PTR/rDNS unnecessarily: this can damage the existing domain's deliverability.
• Publishing DKIM with pasted labels: the DNS record exists but DKIM still fails.
• Overwriting Rspamd DKIM config: the new domain works but the old one stops signing.
• Using the mailbox domain as the IMAP host: clients should connect to the mail server hostname unless you also provision certificates for per-domain mail hostnames.
• Testing only local delivery: always test external delivery and authentication results too.

The safe rule

Think of the mail server hostname as the machine's passport and the hosted domains as tenants. Adding a new tenant should not require changing the passport. Preserve the identity that already works, add the new domain's DNS/authentication carefully, and verify each layer before wiring it into apps.