著者 StalwartをVPSに導入する前の注意点と構成
StalwartはPostfixやDovecotを何に置き換えるのか、直せないポート25とDNSレピュテーションの問題、mailcowを選ぶべき条件をv0.16.19基準で解説します。
Stalwart が 1 つのバイナリに集約するもの
Stalwart は、1 台の VPS 上で単一の Rust バイナリとして実行するメールサーバーです。同じプロセスで SMTP、IMAP、POP3、JMAP、CalDAV、CardDAV、WebDAV に応答します。さらに、独自のスパムフィルター、メッセージストア、ACME クライアントも内蔵しています。従来の構成では、Postfix、Dovecot、Rspamd、アカウント用データベース、独立した証明書ツールを使って同じ処理を実現します。Stalwart はこれらすべてを、1 つのサービス unit と /etc/stalwart/config.json にある 1 つの設定ファイルに置き換えます。
以下の数値、設定名、コマンドはすべて、Stalwart の公式ドキュメント、リリースページ、インストールスクリプトから引用したものです。2026 年 8 月 28 日に確認し、2026 年 8 月 24 日に公開された release v0.16.19 を基準にしています。これらは、自分のサーバーで実行するコマンドです。各コマンドの後に、成功したかどうかを確認する方法を示します。
Stalwart は、GNU Affero General Public License v3.0 (AGPL-3.0) と Stalwart Enterprise License v2 のデュアルライセンスです。一部の機能は enterprise 限定です。公式に記載された HTTP endpoint の一覧では、/scim/v2/* がそのことを示しています。まだ自分で実行していない機能を前提に導入を計画する前に、ライセンス条項を確認してください。
バイナリを 1 つにまとめることで、実際に構成要素を減らせます。ただし、メールが到達するかどうかを左右する 2 つの要素まで減るわけではありません。
ポート 25 と DNS レピュテーションは、使用するソフトウェアを問いません
送信 TCP ポート 25 が最初の関門です。多くの VPS プロバイダーでは、新規アカウントでこのポートをデフォルトでブロックしています。ポート 25 がブロックされていると、サーバーは自分自身とは通信できますが、外部とは通信できません。何もインストールする前にテストしてください。
sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 alt1.aspmx.l.google.com 25正常な結果では、約 1 秒で Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! が出力されます。ブロックされているポートでは、5 秒間待機した後に nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out が出力されます。これは、パケットが上流で破棄され、こちらへ reset を返すものがないためです。この結果になった場合は、プロバイダーにチケットを起票してください。破棄されたパケットを回避して配送できるメールサーバーはありません。
2 つ目の関門は、受信側ネットワークが IP アドレスとドメインをどう評価するかです。対象となるのは、IP アドレスの reverse DNS、SPF、DKIM、DMARC、そして割り当てられたアドレスブロックの送信履歴です。Stalwart の DNS 設定ページには、この作業をどこで行うかが明確に記載されています。reverse DNS レコードは「通常、Stalwart 自身ではなくホスティングプロバイダーが設定します」。このカテゴリの他の設定も同様です。設定はメールサーバー内ではなく、DNS zone とプロバイダーの control panel にあります。
そのため、このページではこれらのレコードを改めて説明しません。説明しているページはこちらです。メールを送信するすべてのサービスで一度だけ SPF、DKIM、DMARC を設定する方法。そもそも自分でメールを運用するかまだ決めていない場合は、自己ホスト型メールに今も価値があるかを率直に検討した記事から始めてください。Stalwart を選んでも、この判断材料は何も変わりません。
Stalwart メールサーバーの実行に必要な小規模 VPS
2026 年 8 月 28 日に確認した Stalwart のシステム要件ページには、次の数値が示されています。アイドル時のメモリ使用量は約 100 MB です。5 ～ 10 ユーザーの小規模な構成であれば、RAM 1 GB で問題ありません。約 5 ユーザーの低トラフィック構成は CPU 1 コアで動作します。同ページでは、「同時実行数とアクティビティが増えると、低レイテンシーと高スループットを維持するために、より多くの CPU コアが必要になる」とも説明されています。デフォルトの上限は、全サービス合計で同時接続 8,192 件です。この値は設定で変更できます。
同ページには最小ディスク容量の指定がありません。そのため、保持するメールの容量に加えて、ストアのコンパクションに必要な余裕を見込んでディスク容量を決めます。
3 つの外向き通信経路が機能しないと、メールとは無関係な理由でサーバーが壊れているように見えます。Web インターフェースのバンドルを https://github.com/stalwartlabs/webui/releases/latest/ から取得します。証明書の取得では https://acme-v02.api.letsencrypt.org/directory に接続します。MX レコードと認証レコードを検索するため、DNS の UDP および TCP port 53 への通信も必要です。最初の経路をブロックする厳格な外向きファイアウォールを設定すると、管理インターフェースのないメールサーバーが起動することになります。
「latest」ではなく、バージョンを固定してインストールする
公式インストーラーは shell script です。実行する前に内容を確認してください。
curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
less install.sh
sudo sh install.sh2026年8月28日にこの script を読むと、実行内容を正確に確認できます。stalwart service account と、必要なディレクトリを作成します。続いて https://github.com/stalwartlabs/stalwart/releases/latest/download からダウンロードします。バイナリは /usr/local/bin/stalwart に mode 0755 で配置されます。設定は /etc/stalwart/config.json、データは /var/lib/stalwart、ログは /var/log/stalwart に保存されます。3つのディレクトリはすべて mode 0750 で、所有者は stalwart です。環境ファイルは /etc/stalwart/stalwart.env に mode 0640 で作成され、所有者は root:stalwart です。script が受け取るのは、任意の install prefix 1つと、FoundationDB build 用の --fdb flag です。version 引数はありません。
この点が重要です。script は常に最新の release を取得するため、1週間空けて構築した2台のサーバーで、同じ code が動作するとは限りません。インストール直後に、自分で binary の version を固定してください。これは、v0.16.19 release notes に記載されている upgrade 方法でもあります。「v0.16.x から upgrade する場合は、binary を置き換えるか、docker pull を実行してください。」
STALWART_TAG=v0.16.19
curl -fsSLO "https://github.com/stalwartlabs/stalwart/releases/download/${STALWART_TAG}/stalwart-x86_64-unknown-linux-gnu.tar.gz"
tar zxf stalwart-x86_64-unknown-linux-gnu.tar.gz
sudo systemctl stop stalwart
sudo install -m 0755 -o root -g root stalwart /usr/local/bin/stalwart
sudo systemctl start stalwart
systemctl is-active stalwartsystemctl is-active stalwart の出力は active になるはずです。それ以外の場合は journalctl -u stalwart -n 50 を確認してください。すべての release asset には対応する .sigstore.json bundle が含まれているため、インストール前にダウンロードの signature を検証できます。
script が作成する unit は User=stalwart として実行され、AmbientCapabilities=CAP_NET_BIND_SERVICE を設定します。この capability により、特権のない account でも port 25、443、465、993 を bind できます。後で独自の unit を作成し、この行を省略すると、通常の user は 1024 未満の port を bind できないため、service は startup 時に失敗します。
初回の管理者パスワードが表示される場所
Stalwart はブートストラップモードで起動し、16 文字の一時パスワードをサービスログに 1 回だけ書き込みます。
sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'セットアップウィザードはポート 8080 の平文 HTTP で待ち受けるため、このポートを公開しないでください。代わりに、SSH 経由でノート PC からトンネル接続します。
ssh -N -L 8080:127.0.0.1:8080 you@your-vps次に http://127.0.0.1:8080/admin を開き、admin としてログインします。パスワードにはログに表示されたものを使用してください。ウィザードでは、サーバーのホスト名、デフォルトのメールドメイン、TLS、ストレージ、アカウントディレクトリ、ログ、DNS の処理方法を設定します。完了したらサービスを再起動し、それ以降は https://<your-host>/admin を使用してください。
パスワードがログの表示範囲から流れてしまった場合は、固定パスワードを設定します。/etc/stalwart/stalwart.env には、この用途のコメントアウトされた設定項目が用意されています。STALWART_RECOVERY_ADMIN=admin:changeme、STALWART_RECOVERY_MODE=true、STALWART_RECOVERY_MODE_PORT（デフォルトは 8080）などが含まれます。コメントを外して再起動し、ログインしたら、再びコメントアウトしてください。Stalwart のハードニングページでは、この認証情報を緊急時専用に保管し、管理者アカウントで IMAP、JMAP、WebDAV にログインしないように説明しています。
同じページには、維持すべきリスナーも記載されています。ポート 25 は受信 SMTP、465 は implicit TLS を使用する submission、993 は IMAPS、443 はすべての HTTP 用です。587、143、4190、110、995、8080 は必須ではないとされており、セットアップ完了後は 8080 を無効にするよう説明されています。
Docker で固定タグを指定して実行する
ドキュメントに記載されているイメージは stalwartlabs/stalwart です。タグ v0.16.19 は、-alpine バリアントとともに 28 August 2026 に Docker Hub で提供されていました。上記のバイナリと同じ理由から、v0.16 の可変タグではなくパッチバージョンを固定します。
services:
stalwart:
image: stalwartlabs/stalwart:v0.16.19
container_name: stalwart
restart: unless-stopped
ports:
- "25:25"
- "465:465"
- "993:993"
- "443:443"
- "127.0.0.1:8080:8080"
volumes:
- stalwart-etc:/etc/stalwart
- stalwart-data:/var/lib/stalwart
volumes:
stalwart-etc:
stalwart-data:このファイルは、ドキュメントに記載された docker run コマンドを Compose 形式で記述したものです。必須ではないリスナーを省略し、セットアップ用ポートは localhost にバインドしています。起動して、同じブートストラップ行を確認します。
docker compose up -d
docker compose logs stalwart 2>&1 | grep -A8 'bootstrap mode'Docker のページには、起動時に固定認証情報を設定する方法として -e STALWART_RECOVERY_ADMIN=admin:mySecretPass も記載されています。ログを読む代わりにこの方法を使う場合は、Compose の environment: キーを使用します。
ドキュメントに記載された完全なポート一覧と、このファイルが短い理由
Stalwart の Docker ページには、443、8080、25、587、465、143、993、110、995、4190 が記載されています。ハードニングのページでは、587、143、110、995、4190 は必須ではないと説明され、セットアップ後は 8080 を無効にするよう求めています。クライアントが実際に要求するものだけを追加してください。スマートフォンで STARTTLS による送信が必要な場合は、587 を公開します。デスクトップクライアントからユーザーが Sieve ルールを作成する場合は、4190 を公開します。
Compose に慣れていない場合は、VPS 向けの Docker Compose 手順で、この構成で使用するファイル構成と名前付きボリュームのモデルを説明しています。特にメールサーバーでは注意が必要です。Docker は独自のファイアウォールルールを書き込んでポートを公開し、そのルールは ufw のルールより先に適用されます。そのため、ufw deny 8080 では Compose が公開したポートを閉じられません。ポートマッピングで 127.0.0.1 にバインドすることで、実際にポートを閉じられます。上のファイルがその設定を採用し、SSH トンネルも引き続き適用できるのはこのためです。
証明書なしのcertbotと、その代償
StalwartはACME（自動証明書管理環境）を直接実装しているため、certbotも更新フックも必要ありません。ドキュメントには4つの検証方式が記載されています。HTTP-01は、port 80でチャレンジ要求に応答します。TLS-ALPN-01は、ACME専用のALPNプロトコルを使用し、port 443で専用の証明書を提示します。DNS-01は一時的なTXTレコードを公開する方式で、ワイルドカード証明書を発行できる2つの方式のうちの1つです。DNS-PERSIST-01は、更新のたびに新しいレコードを書き込む代わりに、長期間有効な認証用TXTレコードを使用します。
代償は、Stalwartがそのportを専有したがることです。TLS-ALPN-01はTLSハンドシェイク自体を完了させることで動作するため、TLSを終端するリバースプロキシの背後では成功しません。そのサーバーでnginxまたはCaddyがすでに443を使用している場合は、StalwartをDNS-01に切り替えるか、専用のIPアドレスを割り当ててください。
DANE と MTA-STS、知っておくべきデフォルト
どちらも Web インターフェースの Settings、MTA、Outbound、TLS Strategies にある MtaTlsStrategy オブジェクトで、TLS 戦略ごとに設定します。dane フィールドのデフォルトは optional です。受信側が TLSA レコードを公開している場合は DANE 検証を試み、公開していない場合は通常の STARTTLS にフォールバックします。require に設定すると、検証可能な TLSA レコードがある場合にだけ配送が進みます。mtaSts フィールドも同様に動作し、デフォルトは optional です。関連するタイムアウトは tlsTimeout（デフォルトは 3 minutes）と mtaStsTimeout（デフォルトは 5 minutes）です。
受信側では、Stalwart は https://mta-sts.<domain>/.well-known/mta-sts.txt に独自の MTA-STS ポリシーを公開できます。この設定には port 443 を開放する必要があります。MtaSts singleton には mode（デフォルトは testing）、maxAge（デフォルトは 7 days）、mxHosts があります。mxHosts が空の場合は、TLS 証明書に含まれるホスト名にフォールバックします。DNS レコードを 2 つ用意します。1 つはメールホストを指す mta-sts CNAME レコード、もう 1 つはポリシー識別子を格納する _mta-sts TXT レコードです。
dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txtTXT の検索結果は v=STSv1; id=... 文字列になり、curl はポリシー本文を返す必要があります。curl が何も返さない場合、port 443 が閉じているか、mta-sts.example.org の証明書が発行されていません。
両方の確認が成功するまで、mode は testing のままにします。証明書が壊れた状態で enforce モードにすると、他のサーバーから自分のサーバーへの配送が停止します。その事実をログではなく、ユーザーから知らされることになります。DANE にも同様の注意点があります。DNSSEC で署名されたゾーンと、リーフ証明書を固定する TLSA レコードが必要です。ACME が更新されるたびに、その TLSA レコードを再公開しなければなりません。発行元 CA を固定するか、更新作業を受け入れてください。
保存時の暗号化はエンドツーエンド暗号化ではない
最も誤解されやすい機能なので、ドキュメントの記載内容を正確に説明します。各ユーザーの平文メッセージは、ディスクに書き込まれる前に、そのユーザーの OpenPGP または S/MIME 証明書を使用して自動的に暗号化されます。encryptAtRest はデフォルトで有効で、受信者が暗号化キーを登録していれば、SMTP または LMTP 経由で到着したメッセージに適用されます。encryptOnAppend のデフォルト値は false です。これにより「追加されたメッセージは変更されず、保存する内容をクライアントが完全に制御できる状態になります」。OpenPGP では古い PGP/Inline ではなく PGP/MIME を使用し、AES-256 または AES-128 で暗号化します。Stalwart はキーを生成しません。ユーザーが ASCII-armored の公開キーをエクスポートし、Account の Public Keys に PublicKey オブジェクトとして登録します。
そのため、盗難されたディスクイメージ、盗難されたバックアップ、配信後にストレージを読み取る運用担当者からメッセージを保護できます。秘密キーがなければ保存されたバイト列は解読できず、管理者も復号できません。
ただし、転送中のメッセージは保護されません。メッセージは、2 台のサーバーが合意した TLS の設定に従ってインターネットを通過し、平文で到着した時点で Stalwart が暗号化します。送信者、送信者のプロバイダー、TLS を解除した中継ホップは、すでに平文を確認しています。
さらに、3 つの制限を明確にしておく必要があります。Sent と Drafts フォルダーはクライアントによって書き込まれます。これは append であり、encryptOnAppend はデフォルトで false なので、設定を変更しない限り内容は平文のままです。2026 年 8 月 28 日に確認したドキュメントはメッセージ内容についてのみ説明しており、envelope データ、ヘッダー、インデックスエントリが暗号化されるとは記載していません。そのため、暗号化されると仮定しないでください。また、キーをアップロードする前に保存されたメッセージが再暗号化されるとも記載されていません。再暗号化されないものとして扱い、確認してください。暗号化された本文に対しても全文検索が機能するかどうかは明記されていません。利用者に提供する前に、使い捨てのアカウントでテストしてください。
ユーザーが秘密キーを失うと、そのユーザーのメールも失われます。設計上、復旧手段はありません。
WKD はメールサーバーの作業ではなく、Web サーバーの作業です
WKD (Web Key Directory) は OpenPGP のもう一方の要素で、別の問題を解決します。ドメイン配下の固定 HTTPS URL で公開鍵を公開するため、送信者のメールクライアントはその鍵を見つけ、メッセージが送信者の端末から出る前に暗号化できます。これはエンドツーエンド暗号化です。Stalwart の保存時暗号化は、ディスク上に保存されたコピーを対象とします。一方を設定しても、もう一方は有効になりません。
Stalwart は WKD を提供しません。2026 年 8 月 28 日に確認したドキュメント上の HTTP エンドポイントには、jmap、caldav、carddav、oauth-authorization-server、openid-configuration、acme-challenge、mta-sts.txt、mail-v1.xml、および autoconfig の well-known パスが記載されています。openpgpkey パスはありません。通常の静的 Web サーバーから提供してください。
仕様では 2 つのレイアウトを定義しています。advanced method では https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe を使用します。direct method では https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe を使用します。この 32 文字の文字列は、小文字化した local part を SHA-1 でハッシュし、z-base-32 でエンコードしたものです。そのため、これらのファイル名を手作業で作成してはいけません。GnuPG が生成します。
gpg --export --armor you@example.org > you.asc
gpg-wks-client --print-wkd-url you@example.org
gpg-wks-client --install-key you.asc you@example.org--print-wkd-url は、sub-domain 形式を使用してクライアントが取得する URL を表示します。--install-key は、WKD のレイアウトを反映したローカルディレクトリツリーへ鍵を書き込みます。デフォルトでは、最上位ディレクトリ名は openpgpkey で、-C dir で変更できます。そのツリーを Web ルートへコピーし、hu ディレクトリの隣に必要な policy ファイルを追加します（空のファイルでも有効です）。最後に curl で自分の URL を取得し、404 ではなく鍵のバイト列が返ることを確認します。
1 台の VPS 上のストレージ
Stalwart はストレージを 4 つの役割に分けます。メールボックスの状態などの構造化レコードを保存するデータストア、メッセージ本文や添付ファイルの生データを保存する blob ストア、全文検索用のインデックスを保存する検索ストア、レートリミッター、認証トークン、セッションデータを保存するメモリ内ストアです。それぞれ異なるバックエンドを指定できます。対応するバックエンドには、RocksDB、FoundationDB、PostgreSQL、MySQL、SQLite、S3 互換オブジェクトストレージ、Azure Blob Storage、Redis、ElasticSearch、Meilisearch があります。
1 台の VPS であれば、答えは明確です。ドキュメントでは、RocksDB を「速度と信頼性のため、Stalwart の単一ノード構成で推奨されるバックエンド」としています。Redis はメモリ内ストアとしてのみ対応しており、データストアや blob ストアにはできません。そのため、開始時に Redis 用の別コンテナを用意する必要はありません。メールボックスがディスク容量を超えるようになったら、後から blob ストアを S3 に移行します。
バックアップ方法はバックエンドに従います。外部データベースの場合は、そのデータベース固有の手順を使用します。組み込みストアの場合、FAQ では /var/lib/stalwart ディレクトリをコピーするよう説明されています。コピーはサービスを停止してから実行するか、ファイルシステムまたはボリュームのスナップショットから行います。実行中の key-value ストアをファイル単位でコピーすると、書き込み途中の状態を取得する可能性があります。その問題は、復元を試すまで判明しません。
Rspamd に代わるスパムフィルター
フィルタリングは同じプロセス内で実行されるため、維持すべき別のデーモンはありません。分類器は、Settings、Spam Filter、Classifier にある SpamClassifier シングルトンで設定します。分類器には、feature hashing を用いた FTRL-Proximal アルゴリズムを使用します。ほとんどのデプロイでは FtrlFh が推奨されるデフォルトです。FtrlCcfh は cuckoo feature hashing に切り替えてハッシュ衝突を減らすもので、大規模なデプロイを対象としています。分類器は継続的に学習します。ユーザーがメッセージを spam または ham として指定すると、そのラベルが今後の判定に直接反映されます。
分類器の周囲には、DNS blocklist、greylisting、フィッシング検出、spam trap、Pyzor が配置されています。手放せないルールがある場合は、milter 経由で SpamAssassin を呼び出すこともできます。
mailcow が適切な選択になる場合
Stalwart には webmail がありません。これは最大の不足点であり、差は埋まっていません。2026年8月28日に確認した mailcow のドキュメントには、SOGo を含む16個のコンポーネントが記載されています。SOGo により、ユーザーはブラウザーから受信トレイを利用でき、CalDAV と CardDAV のインターフェースもすぐに使えます。2025年6月20日付けの Stalwart のロードマップ記事では、組み込み webmail について「計画にはありますが、現在の最優先事項ではありません」と説明しています。Rust と Dioxus で v1.0 の後に実装する予定で、「おそらく2026年のどこか」とされています。2026年8月28日時点で、プロジェクトのブログには webmail の提供開始を告知する記事がありません。したがって Stalwart を使う場合は、自分で Roundcube を導入するか、すべてのユーザーに mail client の設定を求めることになります。
Stalwart には web admin interface があるため、そこが想定される不足点ではありません。2つ目の不足点は、バージョンの成熟度です。FAQ では、Stalwart は 0.x であり、v1.0 より前にデータ構造や設定が変更される可能性があるため、移行が必要になる場合があると説明されています。プロジェクト自身の2026年6月の記事のタイトルは「Zero open bug reports: The road to Stalwart 1.0」です。現在の位置づけは、完成に近いものの、まだ v1.0 ではありません。
3つ目の不足点は、機能一覧には誰も書かない種類のものです。Postfix、Dovecot、Rspamd には、10年分の文書化された回答があります。午前2時にメールがキューに滞留し、ユーザーが待っている状況では、同じエラー文字列に一致する検索結果のほうが、洗練されたアーキテクチャより役に立ちます。その状況であれば、mailcow のインストールガイドでスタック全体を最初から最後まで説明しています。夜通しの作業を短くできます。
1つの binary、1つの config file、JMAP を求め、初期段階のソフトウェアを使うことに抵抗がないなら Stalwart を選んでください。今すぐ webmail が必要で、既存の解決情報が豊富にあることを重視するなら mailcow を選んでください。
既存メールの移行
一般的な方法は、imapsync を使って IMAP から IMAP へ移行することです。移行元と移行先で何が動作しているかは問いません。最初に dry run を実行してください。
imapsync --dry \
--host1 old.example.org --user1 you@example.org --passfile1 /root/.old.pw \
--host2 mail.example.org --user2 you@example.org --passfile2 /root/.new.pw--dryを指定すると、imapsync は「実際には何も実行せず、実行される内容だけを表示」します。そのため、このフラグを外す前に出力を確認してください。各パスワードファイルの先頭行にはパスワードが記録されているため、chmod 600両方を削除してください。
Stalwart には、ほかの多くのサードパーティー製ガイドがまだ反映できていない新しいツールもあります。公式ブログでは、JMAP のインポーター兼エクスポーターである Vandelay（29 May 2026）と、ダウンタイムなしのアップグレードに使う移行プロキシ（10 June 2026）が紹介されています。大規模な移行を計画する前に、両方を確認してください。ほかで見つかる情報のほとんどより新しい内容だからです。
障害のパターンと表示される文字列
管理インターフェースがまったく読み込まれない。 FAQ では、この問題が直接説明されています。Web インターフェースのバンドルは初回起動時に GitHub からダウンロードされるため、github.com への外向き HTTPS 接続がないサーバーでは、サービスは起動しているのにページが空白になります。サーバー上で curl -sI https://github.com/stalwartlabs/webui/releases/latest/ を実行して確認します。その他に挙げられている一般的な原因は、HTTP と HTTPS のスキームが一致していないことと、リバースプロキシがクライアント IP を転送していないことです。
ログに初期パスワードがない。 初期パスワードは bootstrap モードで起動したときに、起動時の1回だけ出力されます。サービスがその後に再起動している場合は、sudo journalctl -u stalwart --since today | grep -A8 'bootstrap mode' で確認する時間範囲を広げます。本当に見つからない場合は、/etc/stalwart/stalwart.env に STALWART_RECOVERY_ADMIN を設定して再起動します。
ローカルプロキシ経由のリレーが拒否される。 v0.16.19 のリリースノートには、host resolves loopback address によってリレールートが拒否される問題の修正が記載されています。この文字列がそのまま表示される場合は、古いビルドを実行しています。回避策を使わず、先にバージョンを固定して更新します。
独自の unit を作成した後、サービスが起動しない。 AmbientCapabilities=CAP_NET_BIND_SERVICE がない場合、stalwart ユーザーは port 25、443、465、993 に bind できません。そのため、最初のリスナーで起動に失敗します。インストーラーが生成した unit から capability の行をコピーします。
証明書がまったく発行されない。 HTTP-01 では port 80 に到達でき、他のプロセスが使用していない必要があります。TLS-ALPN-01 では、443 で TLS ハンドシェイクに Stalwart 自身が応答する必要があります。サーバー上のいずれかの port を別のプロセスが使用していると、他の機能が正常に見えても ACME は静かに失敗し続けます。
FAQ
Stalwart は 1 台の VPS 上で Postfix、Dovecot、Rspamd を置き換えますか？
はい。1 つの Rust バイナリで SMTP、IMAP、POP3、JMAP、CalDAV、CardDAV、WebDAV を処理でき、スパムフィルター、メッセージストア、ACME クライアントも含まれます。4 つのデーモンとそれらを連携する設定の代わりに、systemd の unit 1 つと /etc/stalwart/config.json の設定ファイル 1 つで構成できます。ただし、DNS ゾーンやプロバイダーの port 25 ポリシーは置き換えません。自己ホスト型メールの成否は、実際にはここで決まります。
Stalwart のメールサーバーには、どの程度の RAM が必要ですか？
2026 年 8 月 28 日に確認した Stalwart のシステム要件ページでは、アイドル時はおよそ 100 MB、5 から 10 ユーザーの小規模構成には 1 GB の RAM が適するとされています。トラフィックが少なく、ユーザー数が約 5 人の構成は、CPU コア 1 つで動作します。既定の上限は、すべてのサービスを合わせて同時接続 8,192 件です。この値は設定で変更できるため、上限はユーザー数だけでなく、接続数とメール量に応じて上昇します。最小ディスク容量は公開されていないため、保持するメール量に合わせてディスク容量を決めてください。
Stalwart に切り替えると、メールの到達率は向上しますか？
いいえ。到達率は、VPS から外向きの TCP port 25 が開いているか、IP アドレスに reverse DNS が設定されているか、ドメインに SPF、DKIM、DMARC が設定されているかで決まります。Stalwart は DANE、MTA-STS、SMTP TLS reporting をサポートし、MTA-STS ポリシーを公開することもできます。ただし、これらは通信のセキュリティを制御するものであり、受信側ネットワークが送信元アドレスを信頼するかどうかを決めるものではありません。インストール前に nc -vz -w 5 alt1.aspmx.l.google.com 25 で port 25 をテストしてください。
Stalwart には webmail が含まれますか？
2026 年 8 月 28 日時点では含まれていません。Web 管理インターフェイスは提供されますが、webmail とは別のものです。プロジェクトの 2025 年 6 月 20 日付けのロードマップ記事では、version 1.0 の後に、Dioxus を使って Rust で webmail クライアントを開発する予定とされています。時期は「おそらく 2026 年のどこか」とされており、プロジェクトブログにはまだ提供開始の告知がありません。ユーザーが今すぐブラウザーで受信トレイを使う必要がある場合は、Roundcube を併設するか、SOGo が含まれる構成を使用してください。
Stalwart の保存時暗号化は、何から保護しますか？
各ユーザーのメッセージを、そのユーザー自身の OpenPGP または S/MIME 公開鍵で暗号化してからディスクに書き込みます。そのため、盗難されたディスクやバックアップ、またはストアを読む管理者から、メッセージの内容を復元できないようにします。ただし、これはエンドツーエンド暗号化ではありません。メッセージは平文で到着し、配送時に暗号化されるため、それ以前の各ホップでは内容を確認できます。encryptOnAppend の既定値は false です。そのため、変更しない限り、クライアントが保存する Sent と Drafts は平文のままです。ドキュメントが扱っているのはメッセージ本文だけで、メタデータ、インデックスエントリ、鍵をアップロードする前に保存されたメールの再暗号化については説明していません。推測で判断せず、自分で確認してください。