ランディング · SMTPリレーサービス

プロダクトチームがSMTPリレーサービスを選ぶときは、何を評価すべきですか？

SMTPリレーサービスは、単なるホスト名とポートではなく、管理されたメッセージサブミッションと運用のシステムとして評価します。TLSの必須化、対応するサブミッション用ポート、SMTP AUTHの制御、認証情報の分離、送信ドメインの検証、キューの永続性、ドキュメント化された4xxと5xxの挙動、クォータ、メッセージサイズの上限、配信状態のイベント、バウンスと苦情の処理、サプレッションの範囲、テナントの分離、可観測性、エクスポートのしやすさを確認してください。実際に接続するクライアントとネットワークそのものでテストします。リレーの250応答は以後の処理の責任を移すものであり、受信サーバーへの配信や受信トレイへの到達を証明するものではありません。

サブミッションとサーバー間のリレーを区別する

プロダクトチームは「SMTPリレー」という言葉を、アプリケーションから送信メッセージを受け付けて受信者のメールサーバーに向けて転送する、認証付きのサービスという意味で使うことがよくあります。標準規格では、このサブミッションの役割と、メールサーバー間のリレーとを区別しています。RFC 6409はポート587をメッセージサブミッション用に予約し、サブミッションサーバーがポート25のリレーとは異なる認証、ポリシー、メッセージ修正のルールを適用することを認めています。各プロバイダーに、購入するのがどのインターフェースなのかを確認してください。アプリケーション向けの認証付きサブミッションなのか、受信側のサーバー間リレーなのか、その両方なのか、という点です。ホスト名、ポート、暗号化モード、認証方式、送信者のルール、対応するSMTP拡張を記録します。デスクトップのクライアントでは動作するサービスでも、大量送信のキューには合わないことがあり、サーバー用のリレーはアプリケーションの認証を拒否することがあります。すべてのSMTPエンドポイントが同じように動作すると想定せず、実際の役割そのものをテストしてください。

保護されたサブミッションと安全な認証を必須にする

認証情報やメッセージのコンテンツを、保護されていない接続で送ってはいけません。RFC 8314は平文のサブミッションを廃止されたものとして扱い、サブミッションのトラフィックにはTLS 1.2以降を推奨し、サポートされている場合は暗黙的TLSを優先しています。RFC 4954はSMTP AUTHを定義しており、TLSまたは同等の保護なしには平文パスワードの認証方式を許可しない設定をサーバーが提供することを求めています。評価の際は、証明書の検証、対応するTLSのバージョン、暗黙的TLSとSTARTTLSのポート、ダウングレード時の挙動、暗号化の前に認証が拒否されるかどうかを確認してください。リレーの認証情報はサーバー側の秘密情報ストレージに保存し、環境とアプリケーションごとに別々のプリンシパルを作成し、ダウンタイムなしでローテーションします。権限によって送信ドメインやメッセージの種類を制限できるかも確認しましょう。本番の複数のテナントで1つの共有認証情報を使うと、失効、送信元の特定、インシデントの封じ込めの範囲が不必要に広くなります。

クライアントとネットワークの互換性を確認する

リレーを選ぶ前に、すべての送信元を洗い出します。アプリケーションのライブラリ、キューのワーカー、監視アプライアンス、業務ソフトウェア、複合機、レガシーシステムなどです。ポート587とSTARTTLSに対応しているもの、暗黙的TLSを必要とするもの、最新の証明書を検証できないものや安全に認証できないものもあります。こうした制約は、リレーのアカウントを全体的に弱める理由ではなく、そのクライアントを隔離または置き換える理由です。DNSの名前解決、IPv4とIPv6、送信方向のファイアウォールのルール、接続タイムアウト、プロキシの挙動、TLSのネゴシエーション、AUTH、EHLOの拡張、メッセージサイズの上限、必要であれば国際化アドレスをテストしてください。クラウド環境ではポート25が制限されている場合があるため、プロバイダーの代替サブミッションポートは運用上重要です。互換性のテストは、開発者のノートPCからではなく、本番の各ネットワークから実行しましょう。サポートする設定を文書化し、平文や承認されていないホスト名へのフォールバックはブロックしてください。

受け付け、キュー、再試行を理解する

SMTPの応答は、アプリケーションとの契約の一部です。2xxの完了応答はそのコマンドの成功を示します。メッセージが最終的に受け付けられた後は、SMTPのルールの下で、リレーが配信または後の失敗通知について責任を負います。4xxの応答は一時的なもので再試行の理由になりえますが、5xxの応答は試行したコマンドにとって恒久的なもので、通常は繰り返すのではなく修正が必要です。サービスがメッセージをどのくらいの期間キューに保持するのか、どの失敗を再試行するのか、バックオフのスケジュール、配信状態通知（DSN）をいつ生成するのか、キューに入ったメールがリージョン障害を乗り越えられるのかを確認してください。それでもアプリケーションには、安定したジョブ識別子、上限付きの接続の再試行、あいまいな結果への対策が必要です。DATAの後に接続が切れた場合、やみくもに新しいジョブを作成するとメールが重複することがあります。リレーのメッセージ識別子が得られる場合は保存し、再送信の前に突き合わせを行いましょう。

適切な単位で容量を測る

リレーの上限は、直近1日あたりの受信者数、秒間のメッセージ数、同時接続数、トランザクションあたりの受信者数、メッセージあたりのバイト数、エンコード後の添付ファイルのサイズ、保存されるキューの深さなどに適用されることがあります。月間の総量が大きいプランでも、リリース時のバーストやフェイルオーバーの際にスロットリングされることがあります。アカウントとリージョンごとに現在の上限を確認したうえで、通常時、ピーク時、再試行時、完全なフェイルオーバー時のトラフィックを、SMTPセッション数だけでなく受信者数でモデル化してください。スロットリング時にリレーが一時的な応答を返すかどうか、クライアントが過剰な接続を開かずにそれに従うかどうかを確認します。承認された上限より低い範囲でバックプレッシャーをテストし、残りのクォータ、接続の飽和、キューの滞留時間、スロットリングの応答にアラートを設定しましょう。プロバイダーと受信側のエコシステムがそのトラフィックに対応できるようになるまで、同時実行数を増やしてはいけません。容量は不正利用の境界でもあるため、アカウント全体の上限1つだけでなく、認証情報ごと、テナントごとの制御を評価してください。

送信者の認証とドメインのオンボーディングを検証する

リレーは、正確でレビュー可能なドメインのオンボーディングの流れを提供しているべきです。所有権をどう検証するのか、DKIMセレクターをどう生成するのか、エンベロープのMAIL FROMドメインをどう設定するのか、認証のステータスをどう報告するのかを確認してください。SPFはSMTPのIDを許可するもので、選択されうる2つ目のSPFレコードとして公開するのではなく、既存の有効なレコードに統合しなければなりません。DKIMは署名ドメインを暗号署名に結び付けます。DMARCは、成功したSPFまたはDKIMの識別子が表示上のFromドメインとアライメントしているかを評価し、ドメイン所有者がポリシーを公開してレポートを受け取れるようにします。移行中の署名鍵、セレクターのローテーション、リターンパスのアライメント、DNSの変更を誰が管理するのかを確認しましょう。本番運用の前に、管理されたメッセージを送信し、受信したヘッダーを調べてください。ダッシュボードに「検証済み」と表示されていても、すべての正規のストリームがアライメントしていることの証明にはならず、認証は受信トレイへの到達を保証するものではありません。

使える結果イベントと相関付けを求める

SMTPのサブミッションだけで得られるのはコマンドへの応答であり、プロダクトの運用にはその後の結果が必要です。サービスが、受信サーバーへの配信、バウンス、苦情、拒否、遅延、サプレッションのイベントを、認証されたWebhook、キュー、APIのいずれかで提供しているかを評価してください。イベントの識別子、再試行の挙動、順序の保証、保持期間、署名の検証、受信者の詳細を伏せられるかどうかを確認します。RFC 3461は、選択した条件の下で配信状態通知を要求するためのSMTP拡張を定義していますが、プロバイダーのイベントシステムは、より構造化された運用データを提供できることがあります。受け付け時にアプリケーションのジョブIDをリレーのメッセージIDに対応付け、その後イベントを冪等に取り込みます。受け付け、受信者のメールサーバーへの配信、苦情、バウンス、受信トレイへの到達は、別々の概念として扱ってください。開封やクリックの観測には別途プライバシーのレビューが必要であり、転送に関する事実を上書きするべきではありません。

サプレッションとレピュテーションの境界を評価する

本番用のリレーは、バウンスと苦情への対応を運用上可能にするものでなければなりません。プロバイダー全体、アカウント、サブアカウント、ドメイン、テナントのどの単位でサプレッションリストを保持しているのか、どの種類のイベントでエントリが追加されるのか、送信前にアドレスを照会できるのか、削除はどのように認可されるのかを確認してください。恒久的なバウンスと苦情があれば以後の通常の送信試行を止めるべきですが、一時的な遅延には別のポリシーが必要です。共有アカウントでは、あるテナントへの苦情が別のテナントの正規の受信者をサプレッションしたり、アカウント全体のレピュテーションに影響したりしないかを確認しましょう。専用IPと共有IPの選択肢は、実際の送信量、分離の必要性、ウォームアップの責任者、インシデント対応との関係でのみ検討してください。受信者が想定していないメール、質の悪い受信者データ、無視された苦情を、ネットワークの選択で補うことはできません。バウンスと苦情の変化についてのダッシュボードとアラートを必須にしつつ、移行で運用履歴が消えないよう、正規化したイベントは自社でも保持してください。

テナンシー、可観測性、障害からの復旧をテストする

テスト用のテナントを2つ作成し、各認証情報が承認されたドメインからのみ送信でき、自分のメッセージだけを閲覧でき、自分の上限だけを消費することを証明します。認可されていないFromアドレス、失効した認証情報、サイズ超過のメッセージ、無効な受信者、レート制限の超過、TLSの失敗、ネットワークのタイムアウト、重複した送信、バウンスした受信者、苦情、配信の遅延、Webhookの重複を試してください。ログに、認証情報やメッセージの本文をコピーすることなく、安定したメッセージID、テナント、機密情報を除いた応答の分類、試行回数、タイミングが含まれていることを確認します。プロバイダーには、ステータスの履歴、インシデント時の連絡、リージョンのフェイルオーバーの挙動、データの保管場所、保持期間、エクスポートの形式、サポートのエスカレーションについて確認しましょう。サービスレベルの約束が役に立つのは、アプリケーションがその違反を検知して復旧できる場合だけです。キューにメッセージが入った状態でフェイルオーバーの訓練を行い、代替の構成に検証済みのドメイン、認証情報、クォータ、イベント、サプレッションの状態がそろっていることを証明してください。

SMTPリレーとメールAPIを比較する

既存のソフトウェアがすでにSMTPを使用している場合、またはプロバイダーに依存しないメール転送インターフェースが重要な場合、SMTPサブミッションは有用です。構造化されたバリデーション、リソースID、バッチセマンティクス、直接イベントリソースを提供するHTTPSメールAPIは、新しいアプリケーションにとってより制御しやすい場合があります。レガシーSMTP互換性を必要とするチームは、文書化されたリレーを選択するか、厳密に制御されたアダプターを構築すべきです。新しいプロダクトワークフローを構築するチームは、SMTPの方が自動的にポータブルだと想定するのではなく、認可、キュー、イベント、テナント境界、移行コスト、運用責任についてAPIレイヤーを比較できます。

採点方式でリレーを評価する

提案を依頼する前に要件のマトリクスを作成します。サブミッションのセキュリティ、クライアントの互換性、ドメインのオンボーディング、認証のアライメント、キューの永続性、再試行の意味、クォータ、イベントの網羅性、Webhookの検証、サプレッションの範囲、テナントの分離、可観測性、データの取り扱い、リージョンの設計、サポート、エクスポートのしやすさ、総運用コストに重み付けしてください。致命的な不合格項目は、好みの項目とは別に扱います。平文へのフォールバック、バウンスや苦情の経路がない、検証できないイベント、共有の認証情報、ドメインの所有権チェックがない、ピーク時の需要を下回る上限、といった点は、価格が安いからといって平均化して帳消しにすべきではありません。最終候補のすべてに同じ管理されたテストスイートを実行し、秘密情報を除いたやり取りの記録を保存しましょう。採点は、ロードマップ上の約束ではなく、現在ドキュメント化されている挙動に基づいて行います。移行の前に、少量での並行送信、DNSの変更、イベントの突き合わせ、サプレッションの移管、認証情報のローテーション、ロールバック、旧リレーの最終的な失効をリハーサルしてください。

よくある質問

SMTPのサブミッションとリレーの違いは何ですか？

サブミッションは、認証されたクライアントからの送信メールを、通常はポート587とサブミッション固有のポリシーで受け付けるものです。リレーはメールサーバー間の転送を指し、一般にポート25を使い、信頼とルーティングについて異なるルールが適用されます。

SMTPリレーではTLSを必須にすべきですか？

アプリケーションからのサブミッションでは必須にすべきです。証明書を検証したTLSを必須にし、設定された機密性のレベルが得られない場合は、認証情報の使用やメッセージの送信を拒否してください。対応するポートとダウングレード時の挙動の両方をテストします。

SMTPの250は、受信者がメッセージを受け取ったことを意味しますか？

いいえ。サーバーが完了したSMTPコマンドやメッセージについて責任を引き受けたことを意味します。受信サーバーへの配信、バウンス、苦情、遅延、拒否は、後から届く配信状態通知やプロバイダーのイベントで確認します。

アプリケーションはSMTPの失敗をどう再試行すべきですか？

一時的な4xxとネットワークの失敗は、上限付きのバックオフと安定したジョブIDで再試行します。5xxの失敗は次の試行の前に修正し、DATA後のあいまいな失敗は、メッセージの重複を避けるために突き合わせを行ってください。

SMTPリレーはDKIM、SPF、DMARCを処理しますか？

対応状況はサービスによって異なります。誰がDKIMに署名するのか、どのMAIL FROMドメインを使うのか、どのSPFメカニズムが必要か、DMARCのためにSPFまたはDKIMが表示上のFromドメインとアライメントするかを確認してください。

SMTPリレーよりメールAPIのほうが適しているのはどんなときですか？

構造化されたバリデーション、リソースの識別子、明示的なテナントの認可、バッチの結果、イベントのリソースを必要とする新しいアプリケーションでは、APIのほうが適していることがあります。SMTPは、SMTPに対応した既存のソフトウェアでは引き続き有用です。

出典

さらに学ぶ

SMTPプロトコルとは？アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションのメールワークフローにどう関わるかを解説します。プロダクトチームのためのメールAPI実装ガイド検証済みドメイン、キューを使った送信、安定した識別子、制御された再試行、配信イベント、サプレッション、テナント分離を備えた、安全なメールAPI連携を設計します。