プライベートインフラ / ID 不要プライバシー方針を読む
KoalaVPSのフィールドノート

ご自身で運用するメール。現実的な配信の見込みについて。

セルフホストのメールには、DNS、レピュテーション、フィルタリング、監視、そしてサーバー自体を超えたリカバリ経路が必要です。

まず前提条件を確認してください

アウトバウンド SMTP、逆引き DNS、および必要なポートが実際にサポートされていることを確認してください。KoalaVPS は、ポート 25 のポリシーや IP レピュテーションをまだ保証していません。ホスト名を選択し、その正引きおよび逆引きレコードを確認してください。

認証レコードを公開する

許可された送信者向けにSPF、メッセージ署名用にDKIM、ポリシーとレポート用にDMARCを設定します。お使いのスタックが対応するTLSの転送保護を確認してください。理解していないポリシーをコピーしないでください。誤ったレコードは正規のメールを遮断する可能性があります。

完全なメールスタックを運用

Mailcowなどのスイートは複数のサービスを統合できますが、更新、ストレージ監視、スパム対策、保護された管理が依然として必要です。障害時に備えて代替の連絡経路を確保してください。

配信到達性の作業を見込む

技術的に有効なサーバーでも、受信者によるフィルタリングを受ける可能性があります。求められるメールを送信し、バウンスや苦情に対処し、評判を監視してください。メールボックスのバックアップを一貫して維持し、メッセージと設定の復元をテストしてください。

PTR と外部テストから始める

スタックをデプロイする前に逆引きDNSについて確認してください。PTR、ホスト名、正引きが整合した構成になっている必要があります。複数の外部プロバイダーで受信と送信の配信をテストし、認証結果を確認し、バウンスを監視してください。メールテストのスコアは診断情報であり、将来の受信トレイ到達を保証するものではありません。

復旧用に2つ目の経路を確保する

レジストラ、DNS、サーバー復旧情報をメールシステム自体の外部に保存してください。アカウントリセットがすべて故障したサーバーに届く場合、軽微な障害でも修理が妨げられる可能性があります。メールボックスと設定を一貫してバックアップし、再構築後にユーザーがアクセスを回復する方法を文書化してください。

SMTPの利用可否をデプロイの条件にする

メールスイートをインストールする前に、受信および送信の SMTP ポリシー、リバース DNS の制御、安定したホスト名、メールに適した IP を確認してください。KoalaVPS は、これらの運用能力をローンチ時に検証していません。クリーンな DNS ゾーンを持つドメインでも、ブロックされた送信ポートは修復されず、受信者の信頼も保証されません。このサーバー外に別途のリカバリ用メールボックスを用意し、配信に自前の MTA を使うか、適切に設定された外部リレーを使うかを決定してください。

  • TCP25ポリシーと、選択したスタックに必要な送信/IMAPポートを確認してください。
  • ホストとそのコンテナネットワークがスイートと互換性があるか確認してください。
  • メールボックス、インデックス、スパム/ウイルス対策ツール、バックアップコピーのための容量を確保してください。

スイートを選択し、一貫性のある DNS を公開してください

Mailcow、Mail-in-a-Box、iRedMail はインストールと保守のモデルが異なります。それぞれのレシピを組み合わせるのではなく、選択したプロジェクトがサポートする OS とポート要件に従ってください。メールホスト名の A/AAAA レコード、ドメインの MX、該当する場合は一致する PTR、そして実際にスタックが生成した DKIM 公開レコードを設定します。正当な送信者ごとに SPF を公開し、それらの送信元を検証したうえで DMARC ポリシーを導入してください。未使用または未検証の AAAA レコードは、壊れた IPv6 配信経路を生む可能性があります。

# Substitute your domain and the actual server address:
dig MX example.com
dig A mail.example.com
dig TXT example.com
dig TXT _dmarc.example.com
dig -x 192.0.2.10

配信とリレーの制限を別々にテストする

使い捨てメールボックスを作成し、希望するテストメッセージを複数の外部プロバイダーに送信します。受信した認証ヘッダーを確認し、返信を送信して、キューとバウンスの動作を確認します。未認証の外部クライアントから、お使いのMTAが無関係な第三者アドレス間のメールリレーを拒否することを検証します。認証済みの送信、IMAP TLS、パスワード回復、証明書の更新を確認します。ウェブメールへのログイン成功だけでは、送信SMTPや受信トレイへの配信についてほとんど分かりません。

  • postmasterおよびabuseの連絡先を、独立した復旧経路を通じて監視し続けてください。
  • 失敗を繰り返し再送するのではなく、キューと拒否理由を監視してください。
  • 診断スコアを受信トレイへの配信の約束として扱わないでください。

コントロールプレーンを失わずにメッセージを復旧

メールボックスの内容、データベース、設定、DKIM キー、およびスイートに必要なその他のシークレットを、一貫した手順でバックアップしてください。分離されたホスト上で、小さなメールボックスとユーザーアカウントの復元をテストしてください。受信メールが失敗する場合は、MX、アドレスの到達性、ファイアウォール、キューログを順に確認してください。送信メールが失敗する場合は、ポートポリシー、認証、評判、宛先による拒否を確認してください。更新とメールボックス増加のチェックはスケジュールしたままにしてください。配信到達性はインストール時の節目ではなく、継続的な責務です。

インフラストラクチャを構成する

主導権を握る。
自分の条件でデプロイ。

身元書類は不要。完全な管理者アクセス。暗号資産ネイティブの請求。