iRedMail Multiple Domains: Add New Domains Easily

by

Adding iRedMail multiple domains is built in from the start: every additional domain is a virtual domain in the MySQL (or LDAP) backend, sharing the same Postfix, Dovecot, Amavisd, and ClamAV stack. This guide shows you how to add new domains safely: registering them in the backend, creating mailboxes, pointing DNS records, signing mail with per-domain DKIM keys, and testing end-to-end delivery.

How iRedMail Handles Multiple Domains

iRedMail does not run separate “instances” per domain. Postfix looks up every recipient in the vmail.mailbox and vmail.alias tables, and virtual_mailbox_domains is fed from vmail.domains. Because everything is virtual, one server can serve dozens of domains on the same IP — although, as we will see, a dedicated IP per high-volume domain is often better for deliverability.

There are two ways to add a domain:

  • iRedAdmin Pro: includes an “Add Domain” form that handles SQL inserts, DKIM keys, and per-domain throttling automatically.
  • Manual SQL: free and fully supported — you insert the domain into the backend database yourself and generate DKIM keys with the helper scripts.

This guide covers the manual method used by most community-edition deployments.

Prerequisites

  • A working iRedMail install (1.6.x or newer) with the default MySQL/MariaDB backend.
  • Root (or vmail database user) access to MariaDB on the mail server.
  • The new domain registered, with DNS under your control.
  • Enough resources for growth — a 2 vCPU / 4 GB VPS handles several low-traffic domains. If you need to scale up, Contabo's VPS plans are affordable and iRedMail-friendly, and OVH offers clean, rarely-blocklisted IPs.

Step 1: Add the Domain to the vmail Database

Insert the new domain into vmail.domains. Replace newdomain.com with your domain:

mysql -u root -p vmail
INSERT INTO domains (domain, transport, active)
  VALUES ('newdomain.com', 'dovecot', 1);

No main.cf change is needed — the virtual-domains query table picks up every row automatically. Verify:

postmap -q newdomain.com mysql:/etc/postfix/mysql/virtual_domains.cf

If it prints the domain back, Postfix now accepts mail for it. That single SQL insert is the heart of the iRedMail multiple domains model — no virtual-host config files to maintain.

Step 2: Create Mailboxes and Aliases

Each mailbox is a row in vmail.mailbox. The password hash uses SSHA512; generate it with doveadm:

HASH=$(doveadm pw -s SSHA512 -p 'StrongPassword123!')
mysql -u root -p vmail -e "INSERT INTO mailbox (username, password, name, domain, maildir, quota, active, created)
VALUES ('info@newdomain.com', '\$HASH', 'Info', 'newdomain.com',
 'newdomain.com/i/n/f/info-2026.10.19.00.00.00/', 1024, 1, NOW());"

The maildir value must follow the storage pattern (domain/f/i/r/username-timestamp/) or Dovecot will not find the folder. Aliases are simpler:

mysql -u root -p vmail -e "INSERT INTO alias (address, goto, domain, active)
VALUES ('sales@newdomain.com', 'info@newdomain.com', 'newdomain.com', 1);"

A catch-all (@newdomain.com) is handy for testing, but disable it before production to avoid backscatter spam. With these rows in place, the new domain is fully live inside your iRedMail multiple domains installation.

Step 3: DNS Records Each New Domain Needs

Repeat these for every domain — DNS is per-domain even when the server is shared. Skipping DNS on an iRedMail multiple domains server is the fastest way to end up in spam folders:

  • MX: point the domain to your mail hostname, e.g. mail.primarydomain.com, or an A record mail.newdomain.com on the same IP.
  • SPF: TXT on the domain root, e.g. "v=spf1 mx ~all" — authorizes the server IP via the MX record.
  • DMARC: TXT on _dmarc.newdomain.com, e.g. "v=DMARC1; p=quarantine; rua=mailto:dmarc@newdomain.com".
  • DKIM: the selector record from Step 4 — each domain needs its own key pair and selector.
  • PTR / reverse DNS: have your provider set the IP's PTR to your primary mail hostname. It cannot be per-domain on a shared IP — the main reason heavy senders eventually split domains onto separate IPs.

Step 4: Per-Domain DKIM Signing with Amavisd

iRedMail signs outbound mail via Amavisd + DKIM. With iRedMail multiple domains, each domain needs its own selector and key pair:

amavisd-new genrsa /var/lib/dkim/newdomain.com.pem 2048
chown amavis:amavis /var/lib/dkim/newdomain.com.pem
chmod 0400 /var/lib/dkim/newdomain.com.pem
amavisd-new showkeys

Register the domain in Amavisd's config (/etc/amavis/conf.d/50-user on Debian/Ubuntu):

dkim_key('newdomain.com', 'dkim', '/var/lib/dkim/newdomain.com.pem');
@dkim_signature_options_bysender_maps = ( {
   'newdomain.com' => { ttl => 21*24*3600, c => 'relaxed/simple' },
} );

Publish the selector TXT record from showkeys at dkim._domainkey.newdomain.com, restart Amavisd, then verify with a test to mail-tester.com. A missing or stale DKIM selector is the single most common reason new domains land in spam.

Step 5: TLS Certificate for the New Mail Hostname

If clients connect via mail.newdomain.com, add it to the Let's Encrypt certificate so mail apps show no hostname warnings:

certbot certonly --webroot -w /var/www/html \
  -d mail.primarydomain.com -d mail.newdomain.com
systemctl reload postfix dovecot nginx

Postfix and Dovecot reference the shared cert path, so in an iRedMail multiple domains deployment no per-domain service changes are required — just include every hostname in the SAN list.

Step 6: Optional Per-Domain Transport and Throttling

All domains use the local dovecot transport by default. To relay a domain through another host or dedicated outbound IP:

UPDATE domains SET transport='smtp:[relay.example.com]:587'
WHERE domain='newdomain.com';

Rate limiting per domain is available via iRedAPD's throttle plugin.

Step 7: Test Delivery Per Domain

Never assume a domain works because the first one does. For each new domain:

  • Send from Gmail to info@newdomain.com and confirm it lands in the mailbox.
  • Send from the new domain to Gmail and confirm SPF, DKIM, and DMARC all pass in “Show original”.
  • Run a mail-tester.com check from the new domain's address — aim for 10/10.
  • Seed-test Outlook and Yahoo for inbox placement, not spam.

Common Pitfalls

  • Missing DKIM selector DNS record: signing configured, but the dkim._domainkey TXT record was never published. Gmail shows dkim=neutral or fail.
  • PTR mismatch: reverse DNS points to the primary hostname while the HELO banner advertises something else — align them.
  • Wrong maildir path: a hand-inserted mailbox with a malformed maildir value silently bounces mail. Copy the pattern from a working mailbox.
  • Catch-all left enabled: the testing catch-all turns the domain into a spam magnet.
  • SPF include drift: the new domain copied an old SPF record with include: mechanisms it does not use — keep v=spf1 mx ~all minimal until third-party senders are added.
  • One bad domain poisons the IP: on a shared IP, one domain's spam complaints affect every domain. Monitor each domain's reputation separately in Google Postmaster Tools.

Key Takeaways

  • iRedMail multiple domains work natively — each domain is a virtual domain row in vmail.domains, sharing one Postfix/Dovecot/Amavisd stack.
  • Community users add domains with direct SQL inserts (domain, mailboxes, aliases); iRedAdmin Pro adds a GUI with automatic DKIM handling.
  • Every domain needs its own MX, SPF, DMARC, and per-domain DKIM selector/key pair — DNS is per-domain even on a shared server.
  • Add each new mail hostname to the Let's Encrypt SAN list to avoid TLS warnings.
  • Test inbox placement and SPF/DKIM/DMARC separately for each domain before going live.
  • Watch the shared-IP risk: one misbehaving domain can damage every domain's reputation on the server.

Related Guides

Leave a Comment Cancel reply

Exit mobile version