複数ドメインのメールサーバー：構成と運用費用

30の顧客ドメインを扱うメールサーバーを運用するとします。各ドメインには個別のMX、DKIM鍵、SPFレコード、DMARCポリシー、隔離ルール、送信評価の管理が必要です。問うべきなのは「サーバーを共有できるか」ではありません。PostfixとDovecotは二十年前から対応しています。問題は、ある顧客の配信キャンペーンが共有IPの評価を損ねたとき、ほかの顧客への影響をどこまで抑えられるかです。

複数ドメインを扱うメールサーバーは、多くの運用者に適した構成です。ただし、マルチテナント型ホスティングより安くなると思い込んで導入すると、かえって負担が増えることもあります。本稿では構成方式、テナントを分離する設定の考え方、規模が大きくなると問題になる三つの障害、そして自社運用とTrekMail Agencyなどのホスティングの費用を比較します。ディレクトリやマップを分けるだけで、情報漏えいを防げるわけではありません。

複数ドメイン対応メールサーバーとは

同じ基盤上で、複数のドメイン宛てのメールを受信し、それぞれのドメインから送信するメールシステムです。Postfixの単一インスタンスがclient1.com、client2.com、client3.com宛てのメールを受け取り、Dovecotの単一インスタンスが適切なアクセス分離のもとで三つのドメインのメールボックスを管理します。送信キューを共有しながら、DKIM署名はドメインごとに行います。

これは、広告でいう「複数ドメインのメールホスティング」とは少し異なります。後者は通常、同じ請求アカウントに複数ドメインを登録できるプランを指します。メールサーバーは、そのサービスを実現するPostfixとDovecotの実際の設定です。自分のVPSで運用する方法も、TrekMail Agencyのような事業者にマルチテナント基盤の運用を任せる方法もあります。

複数ドメインを扱う三つの構成方式

10以上のドメインを運用する場合、主に三つの構成方式が候補になります。費用、管理できる範囲、運用の複雑さのバランスはそれぞれ異なります。選択にはインフラ費用だけでなく、技術者が割ける時間も重要です。初期段階で将来の規模を見込んでおけば、二年後に従来の構成が限界に達した際の大規模な作り直しを避けやすくなります。

方式1：ドメインごとにサーバーを用意する

最も単純なのは、顧客ドメインごとにPostfix/Dovecotのインスタンスを設ける方法です。同じインスタンス内には別のテナントがいませんが、共通の管理権限や周辺システムは別途保護する必要があります。各ドメインが独自のVPS、IP、IP評価を持ちます。独立した事業を支える3-5ドメインなら適する場合があります。20+ドメインになると、更新、監視、証明書の更新などの作業がサーバー数に応じて増え、負担になりやすくなります。

方式2：マルチテナント型の共有メールサーバー

代理店でよく使われるのが、Postfix + Dovecotの共通基盤で全顧客ドメインを扱う方式です。virtual_mailbox_domains、ドメイン別DKIM鍵、Dovecotのテナント分離設定を使います。管理する基盤は一つでも、Nドメインを収容できます。目安として10ドメイン前後から費用面の利点が出る場合があり、200ドメイン前後では運用が複雑になることもあります。ただし普遍的な境界ではありません。負荷や要件によっては、ホスティングへの移行や、送信評価のグループごとのサーバー分割を検討します。

方式3：自社構築ではなくマルチテナント型サービスを使う

自社でメールサーバーを運用すると、技術者の作業時間が大きくなり、同等のホスティングより高くつく場合があります。本稿の料金例では、TrekMail Agencyは月額$29、年払い時の月額換算は$23.25/moで、1,000ドメインと、DKIM、SPF/DMARC、送信キュー分離に関する機能を想定しています。現在の提供範囲は確認が必要です。アカウント別キューは顧客ドメイン別のキューやIP評価の独立を意味しません。代理店がPostfix設定を書く必要はありませんが、損益比較は技術者の一時間だけでなく、年間を通した継続作業の総費用とプラン料金で行います。

Postfix + Dovecotの基本構成

2026時点でも、自社運用ではSMTP転送にPostfix、IMAPアクセスと保存、LMTP配送にDovecotを使う構成が広く採用されています。以下の例はDebianまたはUbuntu LTSを想定しています。考え方はほかのディストリビューションにも応用できますが、設定例は不完全でバージョンにも依存します。そのまま本番に投入せず、環境に合わせて検証してください。

virtual_mailbox_domainsとマップファイル

Postfixはvirtual_mailbox_domainsディレクティブで複数の仮想ドメインを扱えます。main.cfにドメインを直接書く代わりに、ハッシュマップを使います。大規模な環境ではSQLやLDAPのバックエンドも選択肢です。

# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps    = hash:/etc/postfix/vmailbox
virtual_alias_maps      = hash:/etc/postfix/valias
virtual_transport       = lmtp:unix:private/dovecot-lmtp

/etc/postfix/vhostsには受信対象のドメインを記載します。ハッシュマップで想定される形式に従い、各行にドメインをキーとして適切な値を置くのであって、名前だけを並べるわけではありません。このLMTP構成では、/etc/postfix/vmailboxは仮想受信者の存在確認に使われ、値が実際のディスク保存先を決めるものではありません。配送と保存を行うのはDovecotです。/etc/postfix/valiasはinfo@client1.com → real-person@client1.comのようなエイリアスを扱います。

Dovecotのドメイン別ディレクトリ構成

Dovecotでは、ドメインごとのディレクトリにメールボックスを配置できます。よく使われる形式は/var/vmail/<domain>/<user>/です。対応する設定例は次のとおりです。

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail

%dはアドレスのドメイン部分、%nはローカル部に展開されます。各ユーザーのメールが所属ドメインの配下に保存されるため、ドメイン単位のバックアップや顧客別の作業がしやすくなります。例えばrsyncで一つのテナントだけをコピーできます。ただし、ディレクトリの分割だけでは安全な分離にならず、認証、権限、アクセス経路の確認も必要です。

PostfixからDovecotへの受け渡しにLMTPを使う

現在の構成では、PostfixからDovecotへの受け渡しにLMTP、Local Mail Transfer Protocolを使うことが一般的です。メッセージごとに別のdovecot-deliverプロセスを起動する方式より、プロセス起動の負担を減らせる場合があります。適切な設定があれば受信者別の容量制限も適用できます。Postfixが必要な権限で接続できるUnixソケットをDovecotに用意します。

ドメイン別のSPF、DKIM、DMARC管理

難しいのは転送そのものより、全テナントのSPF、DKIM、DMARCを一貫して正しく維持することです。DKIM鍵が漏えいした場合の影響を抑えるため、適切な更新方針も必要です。ただし鍵の更新は、悪化した送信評価を回復させる手段ではありません。この運用負担が、自社構築と適切なホスティングを比較する重要な要素になります。

ドメインごとのSPF

SPFでは、SMTPエンベロープの送信者ドメインなど、実際に検証されるドメインが送信元を適切に許可する必要があります。レコードはメールサーバーではなく該当ドメインのDNSにあります。送信IPを追加するときは、その影響を受ける許可設定を更新します。共通のincludeを適切に管理している場合は、そこを変更すればよく、全テナントのDNSを個別に編集するとは限りません。個別の変更が必要ならDNSの操作権限を確認し、顧客やDNS事業者に協力を依頼します。具体的な手順はSPF設定ガイドで説明しています。

ドメイン別DKIMと四半期更新という運用例

自社運用でドメイン数が増えると、DKIM管理の負担も増えます。各ドメインに専用の鍵ペアを用意し、秘密鍵で送信メールを署名し、公開鍵をセレクター付きでDNSに配置します。四半期ごとの更新は方針の一例で、すべての環境に共通する義務ではありません。新しいセレクターを公開し、DNSキャッシュや配送中のメールを考慮してから古い鍵を削除します。100ドメインでは、手作業なら年間400回のDNS更新という計算です。DKIM設定ガイドで更新手順を確認できます。

多数のドメインのDMARCレポート

ドメイン別にDMARCを設定すると、対応する受信側からXML形式の集計レポートが届きます。毎日届くこともありますが、すべての受信側が送るわけではなく、頻度も一律ではありません。解析して正しいテナントに振り分け、ドメインのなりすましや送信サービスの設定ミスといった対処可能な情報を取り出すには、規模によって専用の仕組みが必要になります。DMARC設定ガイドで解析の流れを説明しています。

テナント分離を脅かす三つの問題

共有メールサーバーの品質は、テナント分離の設計と運用に大きく左右されます。以下の三つの問題は、規模が拡大してから現れたり、事故後に初めて発見されたりすることがあります。事前に確認しておきましょう。配送障害が進行している最中の調査は難しくなります。

問題1：共有送信IPの評価低下

同じ送信IPを使うテナントは、そのIPの評価を共有します。あるテナントが同意やリスト品質を軽視した営業メールを送ると、苦情やブロックが生じ、Gmailでの送信制限などを通してほかのテナントにも影響する場合があります。適切な送信基盤の分離は影響を限定できますが、IPを交換・ローテーションしても不正利用の原因は解消しません。受信側の規制を回避する手段として使うべきでもありません。原因と送信品質を改善する必要があり、最悪の場合は共有プール全体の顧客が影響を受けます。

問題2：共有キューの滞留

受信側があるテナントのメールに4xxの一時エラーを返すなどしてPostfixのキューが増えると、共有リソースの競合によってほかのテナントの送信も遅くなる場合があります。Postfixには宛先別の制御がありますが、基盤自体は共通です。50ドメインの環境で500K通のニュースレターを送ると、条件によってはほかの顧客のトランザクションメールに数時間影響する可能性があります。すべての構成で必ず発生するわけではありません。

問題3：認証時のテナント取り違え

Dovecotの認証データベースがドメインを明確に区別していないと、ローカル部が同じユーザーについて、テナントAの利用者をテナントBのレコードで検証してしまうおそれがあります。認証と認可の経路全体でドメインを考慮する必要があります。auth_username_formatには、完全なメールアドレスを示す%uを使い、ローカル部だけの%nを避ける設計が必要になる場合があります。ただし、データベース照会、ユーザーの一意性、アクセス権の検証まで正しく実装しなければ、一行の変更だけでは解決しません。詳しくは複数ドメインのメールホスティングのリスクを参照してください。

自社運用とホスティングの比較

構築するか購入するかは、実際の作業時間の費用で判断します。VPSと帯域だけなら自社運用は安く見えますが、Postfixの調整、ブロックリスト解除の申請、DKIM更新、午前3時の配送障害対応まで含めると見え方が変わります。次の表は三つの費用段階の変化を示す試算であり、現在の料金や能力を保証するものではありません。

このモデルでは、5,000ドメイン未満の多くの環境でホスティングが有利になる可能性があります。ただし料金上限、負荷、人件費、要件によって変わります。例外は、提供事業者の対応地域以外にデータを物理保存する必要があるなど、適切なサービスが満たせない規制要件です。その場合でも全基盤を自社運用するのではなく、例外のテナントだけを自社に置き、ほかは外部に任せる方法があります。

ホスティングに任せられる可能性のある作業

適切なサービスなら、自社で作り運用する四つの仕組みを任せられます。追跡可能なドメイン別DKIM更新、SPF/DMARC設定支援、送信IP評価の段階的な構築と管理、そして集計DMARCレポートの解析です。DNSウィザードが自動でレコードを公開するとは限らず、対応する連携とDNSの操作権限が実際に必要です。連携がなければ顧客側で設定し、どちらの場合も公開済みレコードが正しいか確認します。ドメイン別の評価監視も独立したIP評価を意味しません。自社開発では長い期間を要することがあります。TrekMail Agencyでの提供範囲と利用条件は、現在の製品資料で確認してください。

複数ドメイン向けサービスの比較

候補にはTrekMail、Migadu、Google Workspaceなどがあり、課金や運用モデルは異なります。次の過去の料金に基づく試算は、50の顧客ドメインにそれぞれ約10メールボックス、合計500メールボックスを想定しています。中規模代理店の一例です。現在の価格、課金単位、機能を確認してください。Workspaceではドメイン確認と組織境界にも注意が必要です。同じ組織に異なる顧客のドメインを登録しても、管理権限やデータが自動的に独立するわけではありません。

この仮定に限れば、TrekMail AgencyはMigaduをドメイン課金とした計算より約13×、Workspaceのユーザー課金より約240×安いという結果です。固定料金と単位課金の違いを示す例であって、普遍的な節約の証明ではありません。特にMigaduの課金単位の仮定は検証が必要です。共有IPと専用IPの選択は価格とは別に判断します。専用IPは評価を分ける手段になり得ますが、到達性が自動的に改善するわけではなく、適切な送信品質と量が必要です。

自社運用が適するケース

先ほどの試算は多くの場合ホスティングを支持します。それでも、追加の運用負担を受け入れて自社運用する意味があるケースは三つあります。一般的な傾向だけでなく例外も把握しておきましょう。

一つ目は、適切な事業者では満たせない法令・規制上の要件です。TrekMail、Migadu、検討中のクラウドサービスが運営していない法域に、顧客データを物理的に保存する必要があれば、自社または専用の基盤が必要になる場合があります。運用費用は避けられませんが、そのテナントだけ自社運用し、ほかはホスティングを使う併用方式もあります。一つの例外のために全体を自社運用する必要があるとは限りません。

二つ目は、利用可能なサービスでは満たせないテナント別の専用IPや送信評価の要件です。大量のニュースレターやトランザクションメールを扱う一部の顧客では、送信資源の分離が必要になることがあります。マルチテナント型プランは共有IPを使うことが多いため、専用IPと計画的な評価構築が本当に必要なら、評価グループ別IPを持つVPS運用が候補です。ただし、その必要性を確認してください。専用IPがすべての顧客に有利とは限りません。

三つ目は、社内にすでにメール運用の専門家がいる場合です。別の理由で技術者を雇用しているなら、複数ドメインの運用を追加する限界費用は小さくなることがあります。それでも作業時間は無料ではありません。支払い済みの時間にも、ほかの仕事に使えなくなる機会費用があります。この点まで含めて比較すると、費用判断が変わることがあります。

共有メールサーバーのセキュリティ強化

複数ドメインのメールサーバーは、侵害されると全テナントのメール処理に影響し得るため、価値の高い攻撃対象になります。以下は、見栄えだけの対策ではなく、実際のリスクを下げる管理項目です。

認証付きSMTP投稿には、ポート587でSTARTTLS、またはポート465で暗黙的TLSを使います。認証情報は正しく保護されたTLS接続でのみ送信し、匿名投稿や平文での送信を認めません。ポート25は、ほかのメールサーバーからの正当な受信のために開きます。不正な中継や投稿制御の迂回を防ぐべきですが、ローカル宛ての正当な受信を一律に拒否してはいけません。ポート25が、認証付き投稿の保護されていない代替経路になっていないか確認してください。

テナント別の送信制限は、侵害されたメールボックスによる被害を抑えますが、20分以内のIP評価悪化を必ず防ぐものではありません。正当な送信パターンに合わせて、メールボックス別・時間別とアカウント別・日別の制限を設けます。制限がなければ、例として監視が反応する前に盗まれたパスワードで100K通の迷惑メールが送られる可能性があります。元の比較で挙げられたTrekMailの値は、Starterでメールボックスあたり一日1,000通、アカウントあたり一日6,000通、NanoのSMTP投稿で一時間50通などです。これは制御の例であり、現在の値と適用範囲を確認する必要があります。

管理者アクセスには強いパスワードと2FAを必須にします。メールボックスの2FAも重要で、管理者の2FAより軽視してよいわけではありません。単一アカウントの侵害でもデータ流出や共有送信基盤への被害が生じ得ます。IMAPクライアントでは仕組みに応じてアプリパスワードが必要になる場合があります。管理者アカウントはテナント分離に広範な権限を持つため、特に厳重な保護が必要です。

自社運用のチェックリスト

自社運用では、初期設定と同じくらい日々や週ごとの管理が大切です。適切に保守すればPostfix + Dovecotは長期間運用できますが、監視、更新、安全管理を継続しなければ健全な共有基盤にはなりません。以下は現実的な運用スケジュールの一例です。

毎日：キューの量とテナント別の送信速度を監視します。普段の10×を突然送信し始めたら、キャンペーンか侵害の可能性があるので確認します。送信IPのブロックリスト登録状況をMX Toolboxなどで調べ、ログのローテーション、DMARCレポート取り込み、バックアップ世代管理といった夜間のcron処理が正常終了したか確認します。

毎週：各テナントドメインの取得できた集計DMARCレポートを確認します。新しいニュースレター、決済、営業ツールが加わるたびに、送信元をSPFとDKIMで正しく扱う必要があります。テナント別の容量増加も確認し、30 GBを超えるメールボックスについては、実際のプランに応じてアーカイブやプラン変更を検討します。DovecotのIMAP接続数も監視し、上限到達による同期失敗や問い合わせを予防します。

四半期ごと：採用したセキュリティ方針に従い、ドメイン別DKIM鍵を更新します。例では新しいセレクターを公開して48時間待ち、署名設定を切り替え、さらに48時間の併用後に古いセレクターを削除します。固定時間は保証ではなく、実際のDNSキャッシュ、遅延配送、古い署名を考慮してください。100ドメインなら四半期に約8-12時間、年間約40時間を手作業に使う想定です。ホスティングでも、該当する機能が提供されていれば自動化できる場合があります。

毎年：一つのテナントのメールを新しいDovecot環境へ復元し、バックアップが使えることを検証します。認証バックエンドの監査も行います。SMTPとIMAPのSSL/TLS証明書は、この年次点検とは別に更新を継続監視し、安全なTLSを使います。Let's Encryptの90日という値はこの例の期間であり、今後も一律に適用されるとは限りません。自動更新の失敗や手動対応にも注意します。監査では、Postfixからドメインを削除したのにユーザーが認証可能なままといった古いレコードを探します。

次に検討すること

複数ドメインのメールサーバーは技術的には構築できますが、運用には相当の時間を要することがあります。PostfixとDovecotが基盤を提供しても、ドメイン別DKIM更新やDMARC解析の負担は残ります。代理店にとってホスティングが有利かどうかは、実際の要件と現在の提供条件で判断します。

本稿のTrekMail Agencyの例は月額$29、年払いの月額換算$23.25で、名目上1,000ドメイン × ドメインあたり1,000メールボックス、メールとTrekMail Driveで共有する200 GB、ドメイン別DKIM更新、独自フィルター用Sieveエディター、専用サポート、メールボックスあたり100エイリアス、50顧客ドメインを一括登録するCSV機能を挙げています。名目上の数は無制限の実運用能力を保証せず、容量、送信制限、機能の提供範囲を確認する必要があります。記載モデルでは14日間の無料体験にクレジットカードが必要です。無料のNanoはカードも期間限定の体験も不要で、10ドメイン × 10メールボックスで画面を試す想定です。現在の条件を優先してください。ドメインごとのリスクは複数ドメインのメールホスティングガイドでも確認できます。最新の料金とプラン比較はtrekmail.net/pricingをご覧ください。