バーチャルドメイン

この用語をシェア

バーチャルドメインとは

バーチャルドメイン（Virtual Domain、仮想ドメイン）とは、1台のメールサーバーで複数の異なるドメインのメールを独立して受信・管理する仕組みを指します。例えば example.com、example.net、example.org という3つの独立したドメインを運営していても、物理的なサーバーは1台のままで、それぞれのドメイン宛のメールを別々のメールボックスに振り分けて配送できます。

この考え方はApache HTTPサーバーの「バーチャルホスト」機能に由来しており、メールサーバーの世界でも「1つの物理サーバー上に複数の論理的なドメイン環境を仮想的に構築する」という意味で用いられます。Postfixの公式ドキュメント（VIRTUAL_README）では「virtual domain」という用語が明確に定義されており、大きく分けてバーチャルエイリアスドメイン（virtual alias domain）とバーチャルメールボックスドメイン（virtual mailbox domain）の2種類が存在します。この2つは似ているようで役割が異なり、混同すると設定トラブルの原因になるため、次の「仕組み・詳細解説」で違いを整理します。

バーチャルドメインが典型的に使われる場面は、レンタルサーバー事業者やISPのように、顧客ごとに異なるドメインのメールを1つの基盤で提供するホスティングビジネスです。一方で近年は、自社で複数のブランドサイトやサービスサイトを運営する企業が、コスト削減のために自前のPostfix/Dovecot環境へバーチャルドメインを導入するケースも増えています。

仕組み・詳細解説

バーチャルエイリアスドメインとバーチャルメールボックスドメインの違い

Postfixにおけるバーチャルドメインには2つの実装方式があります。バーチャルエイリアスドメインはvirtual_alias_domainsとvirtual_alias_mapsで定義し、受信したアドレスを別のメールアドレスへ転送するだけで、独自のメールボックスは持ちません。例えば info@example.net 宛のメールを user@example.com という既存のメールボックスへそのまま付け替えるイメージです。一方バーチャルメールボックスドメインはvirtual_mailbox_domains・virtual_mailbox_maps・virtual_mailbox_baseで定義し、ドメインごとに独立したメールボックス（ディレクトリ）を作成して実際にメールを保存します。「複数ドメインの受信箱を本当に分けて持ちたいか、それとも既存アドレスへ転送するだけで済むか」で、どちらの方式を使うべきかが決まります。

メール配送の流れ

送信側からSMTP（ポート25/587）でメールが届くと、Postfixのsmtpdプロセスがまず受信ドメインがmydestination（ローカルドメイン）かvirtual_mailbox_domains（バーチャルドメイン）かを判定します。バーチャルドメインと判定された場合、virtual_alias_mapsでエイリアス変換を試みたのち、該当するメールアドレスがvirtual_mailbox_mapsに登録されていれば、Postfixの配送エージェント（virtualデーモン）がvirtual_mailbox_baseを基準にしたパス（例: /var/mail/vhosts/example.com/user/）へメールを書き込みます。実ユーザーのUNIXアカウントを経由しないため、システムアカウントを増やさずにドメインとユーザーを追加できる点がバーチャルドメインの大きな特徴です。

DNSレコードの設定

バーチャルドメインとして扱う各ドメインは、DNS上ではそれぞれ独立したドメインとして扱われるため、ドメインごとにMXレコードを用意する必要があります。ただし複数のドメインのMXレコードが同じメールサーバーのホスト名を指すことは問題ありません。以下は3つのドメインを1台のメールサーバーで受ける場合のゾーン設定例です。

; DNSゾーン設定例（3ドメインを1台のメールサーバーで受信）
example.com.       IN  MX  10  mail.example.com.
example.net.       IN  MX  10  mail.example.com.
example.org.       IN  MX  10  mail.example.com.
mail.example.com.   IN  A   203.0.113.10

; SPFはドメインごとに個別のTXTレコードが必要（使い回し不可）
example.com.  IN  TXT  "v=spf1 mx a:mail.example.com ~all"
example.net.  IN  TXT  "v=spf1 mx a:mail.example.com ~all"
example.org.  IN  TXT  "v=spf1 mx a:mail.example.com ~all"

ここで注意したいのは、MXレコードやAレコードはサーバー1台分を使い回せても、SPF・DKIM・DMARCはドメインごとに個別のDNSレコードを用意しなければならないという点です。1つのドメインで動作確認したSPFレコードを他ドメインにコピーするだけでは、送信元ホスト名の記述が食い違いレピュテーションが下がる原因になりやすいため、ドメインを追加するたびにSPF/DKIM/DMARCの3点セットを個別に設定・検証する運用ルールを徹底することが実務上の定石です。

認証とDovecotとの連携

バーチャルメールボックスのユーザーはOS上の実アカウントではないため、IMAP/POP3でアクセスする際の認証情報（ユーザー名・パスワード）とメールボックスの場所は、PostfixとDovecotの双方が参照できる形で別途管理する必要があります。小規模構成ではハッシュファイルやテキストファイル（passwd-file）、中〜大規模構成ではMySQL・PostgreSQL・LDAPなどの外部データストアで、ドメイン・ユーザー・パスワードハッシュ・メールボックスパスを一元管理するのが一般的です。Dovecot側ではmail_locationに%d（ドメイン）・%n（ユーザー名）といった変数展開を使い、Postfixのvirtual_mailbox_baseと矛盾しないパス構造を指定します。

具体例・ユースケース

レンタルサーバー・ホスティング事業者

バーチャルドメインが最も広く使われている場面が、レンタルサーバーやホスティングサービスです。数百〜数千件の顧客ドメインを1つのPostfixクラスタで収容し、ドメインとメールボックスの対応関係をMySQLやLDAPで管理することで、顧客が新しいドメインでメールアカウントを申し込むたびに、サーバーを増設せずデータベースへレコードを1件追加するだけで対応できます。

複数ブランドサイトを運営する事業会社

本体サイト example.co.jp とは別に、サービスブランドサイト example-service.jp を展開している企業では、ブランドサイトのお問い合わせ用アドレス（info@example-service.jp）を本体と同じ社内メールサーバーで受けたいというニーズがよくあります。バーチャルドメインを使えば、新しいメールサーバーを別途構築せず、既存のPostfixにドメインを1つ追加するだけでブランドごとのアドレスを運用できます。

グループ会社・M&A後のメールインフラ統合

グループ会社ごとに異なる企業ドメイン（例: company-a.co.jp、company-b.co.jp）を保有したまま、メールインフラだけを統合してサーバー保守コストを下げたいという場面でも、バーチャルドメインが定石として使われます。各社のドメインアイデンティティ（社名入りのメールアドレス）を維持しつつ、裏側のサーバー運用は1チームに集約できるのがメリットです。

開発・検証環境でのステージング用ドメイン分離

本番ドメイン宛のメールと、開発・検証用ドメイン（例: staging.example.com）宛のテストメールを、同じ検証用メールサーバー上でバーチャルドメインとして分離しておくと、本番の受信箱を汚さずに通知メールやアラートメールの送受信テストを完結できます。

メリットとデメリット

混同されやすい用語・類似技術との違い

自社メールサーバー運用への応用

Postfixでの設定

# main.cf
virtual_mailbox_domains = example.com, example.net, example.org
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# /etc/postfix/vmailbox
user@example.com example.com/user/
admin@example.net example.net/admin/

# /etc/postfix/virtual
info@example.com user@example.com
sales@example.net admin@example.net

設定ファイルを編集したら、postmap /etc/postfix/vmailboxとpostmap /etc/postfix/virtualを実行してハッシュデータベース（.db）を再生成し、systemctl reload postfixで反映するのが基本の手順です。virtual_uid_maps/virtual_gid_mapsで指定したvmailのような専用システムユーザーには、ログインシェルを割り当てず（/usr/sbin/nologin等）、メールボックス用ディレクトリの所有者としてのみ機能させるのが定石です。

Dovecotとの連携設定

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/mail/vhosts/%d/%n/Maildir

# /etc/dovecot/conf.d/auth-sql.conf.ext
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

Maildir形式はメール1通を1ファイルとして保存するため、mbox形式に比べてロック競合が起きにくく、バーチャルメールボックス運用との相性が良いとされています。DovecotのSQL認証とPostfixのMySQLマップで同じテーブルを参照させれば、ドメイン・ユーザー・パスワードの管理を1箇所に集約できます。

MySQLデータベース管理

ドメイン数やユーザー数が多い環境では、ハッシュファイルではなくMySQLで管理するのが一般的です。

# main.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

運用・セキュリティ上の注意点

• ドメイン追加時のSPF/DKIM/DMARC設定を忘れない: サーバー側の設定を追加しても、DNS側の認証レコードを追加しなければ新ドメインからの送信メールが迷惑メール扱いされやすくなる。
• vmailユーザーのパーミッション: /var/mail/vhosts以下はvmailユーザー以外の書き込み権限を外し、パーミッションを700〜750程度に絞る。
• バックアップ設計: OSの実ユーザーバックアップの仕組みは使えないため、/var/mail/vhostsディレクトリ全体、またはドメイン別のMaildirを対象にした独自のバックアップジョブを組む必要がある。
• クォータ管理: Dovecotのquotaプラグインでドメイン・ユーザー単位のメールボックス容量上限を設定し、特定ドメインの肥大化がディスク全体を圧迫しないようにする。
• 単一障害点への対策: 全ドメインが1台のサーバーに集約されるため、冗長化構成（プライマリ/セカンダリMX、レプリケーション）の検討優先度が通常のシングルドメイン運用より高くなる。

関連ブログ記事

• Docker Mailserver完全ガイド

まとめ

バーチャルドメインは、複数の独立したドメインのメールを1台のサーバーで効率的に管理する仕組みです。バーチャルエイリアスドメインとバーチャルメールボックスドメインという2つの方式の違いを理解し、DNS側のMX/SPF/DKIMをドメインごとに正しく整備することが、安定運用の前提条件になります。自社で複数サイトやブランドを運営する場合、1台のメールサーバーで統合管理すれば、コストとリソースを最適化できる一方、単一障害点化や設定漏れのリスクにも配慮した設計・運用が求められます。

よくある質問（FAQ）

この用語についてもっと詳しく

バーチャルドメインに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。