Mailcow の代替とメールサーバー自営の実際のコスト

Mailcow の代替を検討する人は、すでに Mailcow を運用したか、必要な取り組みがわかるほど文書を読んでいることが一般的です。Mailcow は実際に優れたソフトウェアです。完全で適切に保守されたメールスタックを一日の午後に構築し、すべて自分で管理できます。

したがって、代替を探すことはソフトウェアの評価ではありません。動作するかではなく、継続運用のコストが外部へ任せる費用より低いかが問題で、その大半はサーバー料金以外にあります。

セルフホスティングで実際に必要なこと

Mailcow の前提条件は率直で、検討の出発点に適しています。公開 IP アドレスを持つ新しいサーバーが必要です。公式文書では、多くの個人環境に 6 GiB の RAM と 1 GiB のスワップが適し、五人から十人の利用者には 8 GiB を推奨しています。

受信用に 25、80、443、465、587、993、995、4190 の各ポートも開く必要があります。IP の PTR レコードはホストの FQDN と一致させます。文書には、ClamAV と Flatcurve 全文検索エンジンが多くのメモリを使い、無効化もできるとあります。最初の調整内容を示す情報です。

どれも不合理ではありません。ただし項目は多く、メールが必要な瞬間にどれかが問題になる可能性があります。

多くの人が Mailcow の代替を求める理由

要件一覧では解決できず、代替を探す大きな理由になるものがあります。新しい IP アドレスには送信評価がなく、評価をインストールすることはできません。

SPF、DKIM、DMARC、PTR の一致、TLS がすべて正しくても、Microsoft が数週間メールを迷惑メールに分類することがあります。これは一晩で直せる設定ミスではありません。受信側が初めて見る IP を慎重に扱っているためです。IP のウォームアップには、少量で良好に受信されるメールを時間をかけて安定して送り続ける必要があり、一週間の問題で成果が失われることもあります。

関連する問題が二つあります。多くのホスティング事業者は送信ポート 25 を標準で遮断し、審査後にだけ開放するため、開始前に計画が止まる場合があります。また IP 範囲には履歴があり、以前の利用者が傷つけたアドレスと、自分に原因のないブロックリスト掲載を引き継ぐ可能性があります。

ホスティング事業者は、保守および監視され、すでに信頼履歴のあるプールを提供します。料金の多くはこの価値に対するものです。

3am に作業するのは誰か

インストールは一日の午後ですが、運用は何年も続きます。

証明書は更新されますが、時には失敗します。Docker イメージの更新で互換性が壊れる場合があります。削除できないメールでディスクが埋まります。存在を忘れていたコンポーネントに CVE が発生します。迷惑メール規則がずれ、再学習が必要になります。復元したことのないバックアップは仮説にすぎないため、復元テストも欠かせません。

これだけで Mailcow の代替が必要になるわけではありません。技術者が自分のメールを運用するなら、楽しい趣味になり得ます。企業では、担当者が休暇中にメールが止まったらどうなるかを問うべきです。良い答えがなければ、メールサーバーだけでなく、一人の従業員への依存も抱えています。

実際のコスト比較

Mailcow の代替を選ぶ前に VPS 料金とサブスクリプションを比べると、Mailcow は簡単に勝ちます。より完全な比較は次のとおりです。

Mailcow 自体は無料で、規模にかかわらずメールボックス単位の料金がないことは大きな利点です。自分の時間にコストがなく作業を楽しめるなら、セルフホスティングのほうが安く、この記事は対象外です。

時間に価格があるなら、作業時間を数値化して再計算してください。多くの場合、月に約二時間で結果が逆転し、メール管理が月二時間未満に収まり続けることはまれです。

ホスティング型の代替が取り戻すもの

運用負担以外にも、Mailcow ほど完全なスタックでも自作しにくい機能が三つあります。

自分でホストしないメールボックスの閲覧。 Google Workspace や Microsoft 365 を使い続ける顧客のメールボックスは、定義上セルフホストできません。IMAP で接続すれば、ほかのメールと同じ一覧に表示し、返信は元の事業者から送って認証の整合性を保てます。統合受信トレイを参照してください。

結果を検証する移行。 IMAP コピーはフォルダーの一部を残しても成功と報告する場合があります。後で両側の固有 Message-IDs を照合すれば、不足したフォルダーを特定できます。これが一括移行で、セルフホストのメールボックスを離れる日に重要です。

API によるプロビジョニング。 Mailcow にも実用的な API があります。ここでの違いは、同じ操作が MCP サーバーを通じてアシスタントに公開される点です。ドメイン、DNS レコード、三十個のメールボックス作成を、スクリプトではなく依頼として実行できます。

一般的な機能は両方に共通し、そうあるべきです。IMAP、SMTP、Sieve フィルター、CalDAV と CardDAV、Web メールクライアントです。

セルフホスティングを続けるべき場合

次のいずれかに該当するなら、Mailcow の代替は適切ではありません。

• データ主権が必須要件で、管理下のハードウェアにメールを置く必要がある。
• 数千のメールボックスがあり、どの事業者でもアカウント単位の料金が合理的でない。
• インフラ運用が仕事または趣味で、作業時間をコストと見なさない。
• カスタム Rspamd 規則、特殊な Dovecot プラグイン、データベース直接アクセスなど、ホスティング事業者が提供しないものが必要。
• IP のウォームアップが済み、安定している。これは最も交換しにくい資産。

最後の点は十分に検討する価値があります。安定稼働し、信頼され、適切に管理されたセルフホストサーバーは価値があり、その信頼を別の場所ですぐに再構築することはできません。現在順調なら維持できます。

立場別の結論

インフラ運用そのものが目的ならセルフホスティングは妥当ですが、メールが単に動けばよい場合には割に合わないことがあります。

作業を楽しむ一人の利用者。 Mailcow を維持しましょう。無料で自分のものになり、作業時間はコストではなく趣味です。以下の利点もそれを上回りません。

メール停止が誰かの問題になるチーム。運用できるかではなく、できる人が休暇中ならどうなるかが問題です。ホスティング型の代替は、証明書更新、CVE、ディスク不足、自分に原因のないブロックリスト掲載を引き受けます。さらに DNS の適用、メールボックスの一括作成、パスワードを渡さない設定招待、メールボックス別の割り当てと二要素認証、正式なメンバーを持つ共有メールボックスなど、自作が必要な機能を追加します。

顧客向けメール。セルフホスティングは、ホスティング会社になることを意味します。顧客別ブランド、大規模プロビジョニング、検証、顧客スタッフの言語に対応した画面、MCP 経由で操作するアシスタントが必要です。これはサーバーではなく製品であり、週末だけでは作れません。

メールサーバーを運用したいなら Mailcow を維持し、メールサーバーに依存する事業を運営したいなら代替を選びます。

よくある質問

Mailcow のインストールは難しいですか？

いいえ。Docker Compose を使用し、文書も良好です。難しいのはインストールではなく、アップグレード、ディスク不足、自分に原因のないブロックリスト掲載に対応しながら三年間運用することです。

Mailcow に必要な RAM はどれくらいですか？

文書では、多くの個人環境に 6 GiB と 1 GiB のスワップ、五人から十人には 8 GiB を挙げています。ClamAV と全文検索エンジンはメモリ消費が大きく、どちらも無効化できます。

セルフホストサーバーで良好な配信到達性を得られますか？

はい。正しい SPF、DKIM、DMARC、PTR、きれいな IP、慎重なウォームアップが必要です。実現できますが時間がかかり、侵害された一つのアカウントによる迷惑メールで数か月の成果が失われることもあります。

iRedMail、Mailu、Poste.io ではどうですか？

同じトレードオフの別形態です。スタックは異なっても、運用負担と IP 評価の問題は残ります。セルフホスト製品同士の選択は好みですが、重要なのはセルフホスト自体を選ぶかです。

メールを失わずに Mailcow から移行できますか？

はい。Mailcow は標準 IMAP に対応するため、CSV から実行する通常のメールボックスコピーで移行できます。後で結果を移行元と照合し、転送内容を確認できます。

ホスティング型 Mailcow 代替は大規模になると高価ですか？

数千メールボックスを超えると通常はそうなり、セルフホスティングが有利です。それ未満では、自分の時間を正直に評価するとホスティングが有利な場合が多くあります。当社プランは利用者単位ではなく階層ごとに上限を設け、Agency では最大 1,000 ドメイン、各 1,000 メールボックスです。

移行後もサーバー側フィルターを使えますか？

はい。Sieve は標準なので、既存スクリプトに対応するものがあり、一つのクライアント内ではなく配信時にすべての端末へ適用されます。