プライベートで配信可能なメール用にVPSを準備する
独自のメールサービスを構築する前に、IPレピュテーション、SMTPの可用性、DNS認証、逆DNSを確認します。
概要
プライベートメールのホスティングには、メールサーバーのインストール以上のものが必要である。ポートの可用性と逆引き DNS を確認し、SPF、DKIM、DMARC を設定し、アドレスの評判を考慮する。認証は受信者がメッセージを評価する助けになるが、受信トレイへの配信を保証するものではない。保守と復元可能なバックアップは依然として不可欠である。
メールボックス制御をメッセージ配信から分離する
セルフホスティングはメールストア、アカウント、保持、ソフトウェア設定を制御できます。また、可用性、パッチ適用、スパムフィルタリング、バックアップの責任も負います。そのトレードオフは個人ドメインや小規模チームに適するかもしれませんが、一度きりのインストールではなく継続的なサービスです。
他のプロバイダーへの配信は別の課題です。受信側は送信IP、ドメイン履歴、認証、メッセージの挙動、および独自のポリシーを評価します。ローカルで動作するメールアプリケーションでも、そのメッセージが遅延、拒否、またはスパムに分類されることがあります。
展開前にアドレスを調査する
割り当てられたIPアドレスには、以前の利用者からの履歴が伴うことがあります。関連する評判とブロックリスト情報を確認し、メールサービスを開始する前に調査結果を検証してください。既知のブロックリスト掲載がないことは有用な出発点であり、そのアドレスがこれまで一度も使われたことがない証明でも、受信箱への配信を保証するものでもありません。
送信ポート25、専用アドレス指定、逆引きDNSを設定する能力についてホストに尋ねてください。rootアクセスだけではSMTPを送信する許可や、プロバイダのPTRゾーンを制御する権限は与えられません。IPv6固有の制限を含め、まずルールと技術的な能力を確認してください。
認証を使ってドメインの権威を確立する
SPFは、エンベロープドメインの送信を許可されたシステムを公開します。すべての正当な送信者を列挙し、メカニズムの検索制限を尊重し、-allのようなハードフェイル終端を強制する前にテストしてください。受信側は独自の処理判断を行います。SPFは、受領や拒否を自動的に保証する指示ではありません。
DKIMは、ドメインが管理する鍵で選択されたメッセージヘッダーと内容に署名します。対応する公開鍵をセレクターの下で公開し、署名鍵をサーバー上で保護してください。有効な署名は、メッセージが望ましいまたは無害であることを証明するのではなく、許可された署名と対象内容の完全性を示します。
表示される送信者をDMARCに一致させる
DMARCは、表示されるFromドメインを認証に関連付けます。合格には、一致するSPFの結果または一致するDKIM署名が必要であり、メッセージ内のどこかで無関係なドメインが認証されただけでは不十分です。適切なポリシーを公開し、集計レポートを調査して、見落としている可能性のある正当な送信者を発見してください。
ドメインの送信経路が不確かな場合は監視から始め、正当なトラフィックが正しく一致したら検疫や拒否へ移行してください。報告用アドレスと保存されたレポートには運用情報が含まれるため、慎重に扱ってください。コピーした過去の設定ではなく、現在のDMARCドキュメントを使用してください。
DNSの例では、予約済みドメインとドキュメント用アドレスを使用しています。すべての値を実際の送信ドメイン、アドレス、報告用メールボックスに置き換えてください。そのまま公開しないでください。
example.invalid. TXT "v=spf1 ip4:203.0.113.45 -all"
_dmarc.example.invalid. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"逆引きDNSとサーバー識別情報を一致させる
メールIPアドレスは、適切なホスト名を指すPTRを持ち、そのホスト名は同じアドレスへ正引きで解決されるべきです。サーバーのEHLO名を一貫して設定してください。通常、プロバイダがPTRレコードを管理するため、そのサポートされた手順を通じて設定を整えてください。
MXとアドレスレコードを公開し、TLSを設定して証明書の更新をテストしてください。IPv6経由で送信する場合は、そのアドレスの評判と逆引きDNSを別々に評価してください。その経路を正しく維持できないのであれば、VPSに含まれているというだけの理由でIPv6送信経路を公開したり使用したりしないでください。
大量送信の前に安全なメールサービスを構築する
保守されているメールスタックを選び、必要なサービスのみを公開してください。投稿には認証を要求し、オープンリレーを防ぎ、クライアントアクセスには適切なTLSを使用してください。独立した受信者でテストし、メッセージ認証結果と配信応答を検査してください。
履歴を確立する間は、控えめで予想される範囲のトラフィックを送信してください。アカウントを侵害から保護し、バウンスを処理し、無差別な一括メールを避けてください。認証レコードと未記載のアドレスは、悪用されたトラフィック、盗まれたメールボックス、受信側が信頼しないドメインを補うことはできません。
- インストール前にSMTP権限とPTRサポートを確認してください。
- 実際に配信されたメッセージからSPF、DKIM、DMARCの一致をテストしてください。
- サーバーがオープンリレーでないことを検証してください。
- クライアントのTLSと証明書の更新を確認してください。
- 繰り返し再送するのではなく、バウンス応答を確認してください。
- 一貫した正当な送信パターンを維持してください。
ホスティングのプライバシーが何をカバーし、何をカバーしないかを理解する
最小限の登録データと私的な支払い方法は、サーバーとその運用者の間の請求上の結び付きを減らすことができます。DNSの登録情報、連絡先アドレス、メールヘッダー、アカウント復旧は、他の結び付きを生み出すことがあります。ホスティングアカウントがプライバシー境界の全体を定義すると仮定するのではなく、それらの層を確認してください。
セルフホスティングは、通常のメールをエンドツーエンド暗号化するものではありません。TLSは特定のトランスポート接続を保護しますが、メッセージ内容はエンドポイントや中間のメールストアで依然として読める可能性があります。通信相手が内容の機密性を必要とする場合は適切なエンドツーエンドツールを使用し、メールが必然的に露出するメタデータを考慮してください。
継続的な運用と復旧を計画する
オペレーティングシステムとメールソフトウェアを最新の状態に保ち、キューの増加とリソース使用量を監視し、診断情報には適切な保持期間を選ぶ。バックアップを暗号化し、メールボックスのデータ、設定、署名鍵を含める。キューに入ったメールを誤って重複送信することなく、復元をテストする。
作業負荷について現実的に考える。小規模な個人ドメインなら管理できるかもしれないが、大量送信者にはより多くの監視と慎重な運用プロセスが必要である。アドレスの品質、ルートの制御、DNS のサポートが基盤を確立し、定期的なメンテナンスがサービスの有用性を獲得し維持する。