Hosting Multiple Email Domains on Single Server: DNS MX Record Configuration Best Practices


2 views

When configuring multiple domains (virtual hosting) on a single email server, DNS setup becomes critical. The core challenge lies in maintaining proper mail routing while preserving domain identity. Let's examine two production-tested approaches with technical implementation details.

This method uses a unified mail hostname across all domains. Here's a real-world BIND zone file example:

; example1.com zone
@  IN  MX  10  mail.primaryhost.com.
mail.primaryhost.com. IN A 203.0.113.45

; example2.com zone  
@  IN  MX  10  mail.primaryhost.com.
; No separate A record needed

Pros:

  • Simplified DNS management
  • Single point for SPF/DKIM/DMARC configuration
  • Common in shared hosting environments

Each domain maintains its own mail hostname pointing to the same IP:

; example1.com zone
@  IN  MX  10  mail.example1.com.
mail.example1.com. IN A 203.0.113.45

; example2.com zone
@  IN  MX  10  mail.example2.com.  
mail.example2.com. IN A 203.0.113.45

Implementation Notes:

  • Requires proper PTR record configuration
  • Needs separate SPF records per domain
  • Works better with TLS certificates (SAN or wildcard)

Postfix Configuration Example

For either approach, your mail server needs virtual domain support:

# main.cf
virtual_mailbox_domains = example1.com, example2.com
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

Dovecot Setup

# dovecot.conf
mail_location = maildir:/var/mail/vhosts/%d/%n
first_valid_uid = 5000
last_valid_uid = 5000

Both approaches require careful attention to:

  • SPF records (v=spf1 mx ~all for each domain)
  • DKIM signing (separate keys per domain recommended)
  • DMARC policies (domain-specific reporting)
  • PTR record must match your primary mail hostname

For most self-hosted scenarios, Approach 2 provides better:

  • Domain separation in mail headers
  • Flexibility for future migrations
  • Compatibility with strict spam filters

However, Approach 1 may be preferable for:

  • Large numbers of domains
  • When using cloud-based filtering services
  • Simplified certificate management

When running a mail server with Postfix/Dovecot on a single IP address, DNS configuration becomes critical for proper mail routing. Both approaches you've discovered are technically valid, but they serve different architectural philosophies.

This method treats your mail server as a unified mail hub. Here's a typical Postfix configuration snippet for this approach:


# main.cf
mydestination = $myhostname, localhost.$mydomain, localhost
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailboxes.cf
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_aliases.cf

This creates separate identities for each domain while still using the same physical server. The Postfix configuration would include:


# main.cf
mydestination = $myhostname, localhost.$mydomain, localhost
smtpd_banner = $myhostname ESMTP $mail_name
virtual_mailbox_domains = example1.com, example2.com

For DKIM/DMARC compatibility, Approach 2 provides better domain isolation. Here's how you'd configure separate DKIM keys:


# opendkim.conf
Domain                  example1.com
KeyFile                 /etc/opendkim/keys/example1.com.private
Selector                mail

Domain                  example2.com
KeyFile                 /etc/opendkim/keys/example2.com.private
Selector                mail

For Approach 2, your zone files would look like this:


; example1.com zone
@        IN MX 10 mail.example1.com.
mail     IN A     203.0.113.45

; example2.com zone  
@        IN MX 10 mail.example2.com.
mail     IN A     203.0.113.45

For internal resolution, your BIND configuration might include:


zone "example1.com" {
    type master;
    file "/etc/bind/zones/db.example1.com.internal";
};

zone "example2.com" {
    type master;
    file "/etc/bind/zones/db.example2.com.internal";
};

For most self-hosted scenarios, Approach 2 provides better domain separation and easier troubleshooting. The slight additional DNS overhead is worth the cleaner architecture, especially when dealing with security protocols like DMARC.