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

プロダクトチームはGoogleのSMTPリレーサービスを選ぶときに何を評価すべきか

Google WorkspaceのSMTPリレーは、その管理、ID、クォータのモデルがワークロードに合う場合にのみ選んでください。Workspaceのドメインと管理コンソールの設定を誰が所有しているか、アプリケーションが許可リストに登録された安定した公開IPアドレスか、TLSで保護されたSMTP認証を使えるか、どのエンベロープ送信者が許可されるか、TLSをどのように強制するかを確認します。導入前に、Googleの現在のユーザー単位、顧客単位、トランザクション単位の上限をモデル化してください。一時的なエラーと恒久的なエラーをテストし、SMTPの応答を保存し、表示される送信者をSPF、DKIM、DMARCで認証し、受け付け、受信サーバーへの配信、受信トレイへの到達を別々の結果として扱います。

まずワークロードと管理面での適合性を確認する

GoogleのSMTPリレーサービスは、smtp-relay.gmail.com を経由して送信するアプリケーション、デバイス、メールサーバーのための、Google Workspaceの管理用の経路です。汎用の匿名SMTPエンドポイントとしてではなく、組織のWorkspaceとメールセキュリティの境界の一部として評価してください。Workspaceの特権管理者である担当者、アカウント内のドメイン、送信元システム、公開の送信元IPアドレス、送信者アドレス、メッセージの種類、ピーク時と1日あたりの受信者数、添付ファイルの傾向、インシデント時の連絡先を特定します。ワークロードが、トランザクション、社内の運用、ユーザーが作成するもの、購読者向けの一斉送信、デバイスが生成するもののどれにあたるかを判断します。認可、同意、サプレッション、監査、レピュテーションの要件が異なるため、これらの種類は分けておいてください。下位の環境が本番の経路や顧客のアドレスを使えないことを確認します。リレーは許可されたメッセージを転送できますが、ビジネス上のイベントが正当かどうか、受信者が同意したかどうか、アプリケーションの状態を先に進めるべきかどうかを判断するものではありません。

IPアドレスによる認可とSMTP認証を比較する

Googleの現在の設定では、管理者は、リレーの受け付けを指定した公開IPアドレスに制限したり、TLS上でのSMTP認証を必須にしたり、文書化された設定に従ってポリシーの選択肢を組み合わせたりできます。安定したIPアドレスによる認可は、管理されたデータセンターや固定の送信ゲートウェイには適していますが、変化するクラウドのNAT、複数リージョン、フェイルオーバー用のサービス、サードパーティのネットワークの背後では壊れやすくなります。SMTP認証はWorkspaceのアカウントと送信ドメインを識別しますが、認証情報のライフサイクル、ユーザーの状態、多要素認証やポリシーとの相互作用、そしてTLSの厳格な必須要件が加わります。1つの広範な認証情報を、テナントや無関係なアプリケーションの間で使い回さないでください。それぞれの選択肢について、誰がIPアドレスやアカウントを追加できるか、変更をどうレビューするか、侵害をどう検知するか、アクセスをどう取り消すか、フェイルオーバー時に何が起きるかを文書化します。許可するIPアドレスの範囲は実用的な範囲でできるだけ小さくし、内部アドレスをコピーするのではなく、実際の実行環境から公開の送信元アドレスを確認してください。

許可する送信者とドメインのIDを定義する

管理コンソールのリレー設定で、どの送信者を許可するかを制御します。Googleは、登録済みのAppsユーザーや所有するドメインのアドレスに紐づくオプションに加え、不正利用のリスクが高まる、任意のアドレスを許可するより広いオプションも文書化しています。ワークロードの要件を満たせる最も狭いオプションを選んでください。SMTPのエンベロープ送信者は、表示されるFromやReply-Toのフィールドとは別に洗い出します。Googleによると、送信者がアカウントのドメインの外にある場合、SMTP AUTHや、HELOまたはEHLOで提示されたドメインによって、エンベロープ送信者の識別方法や書き換えが変わることがあります。所有する送信者のモデルの代わりに書き換えに頼らないでください。アプリケーション、テナント、メッセージの種類、エンベロープ送信者、表示されるFromドメイン、Return-Pathの対応関係について、承認済みのマッピングを必須にしてください。Googleに接続する前に、ユーザーが指定した任意のヘッダー、改行インジェクション、テナントをまたいだFromアドレスをブロックします。設定全体を緩めることなく、空のエンベロープ送信者も含めて、バウンスのルーティングと不在通知メッセージをテストしてください。

転送経路のセキュリティを意図して必須にする

Googleの現在のリレーのガイドでは、TLSに対応したオンプレミスのシステムをポート587の smtp-relay.gmail.com に向けるよう案内しており、SMTP認証にはTLSが必要であると説明しています。管理コンソールの設定で、送信サーバーからの接続にTLSを必須にすることもできます。文書化された旧来の制約について期限付きの例外がない限り、本番環境ではTLSを必須にしてください。サーバー名、証明書チェーン、対応するプロトコルと暗号スイートのポリシー、STARTTLSのネゴシエーション、失敗時の挙動を検証します。必須のTLSを確立できない場合、クライアントは安全側に倒して失敗させる必要があります。黙って平文にフォールバックすると、ポリシーが無意味になります。SMTPの認証情報はマネージドなシークレットストアで保護し、コマンドライン、URL、ソースコード、ログ、分析ツール、クラッシュレポート、チケットに含めないでください。転送経路のTLSが保護するのはGoogleまでの1ホップであり、メッセージのライフサイクル全体やメールボックスではありません。機密性の高い内容には、アプリケーションレベルの制御、データの最小化、保持期間、そして別途エンドツーエンド暗号化についての判断が必要になる場合があります。

リレーを選ぶ前に現在のクォータをモデル化する

Googleの現在のSMTPリレーの設定ドキュメントによると、各ユーザーは24時間あたり最大10,000通、ユニークな受信者10,000人までに送信でき、トライアルではさらに低い上限が適用される場合があります。また、SMTPトランザクションあたり100人の受信者の上限と、顧客単位、ピーク時、1日あたりの追加の制御も文書化されています。これらは現時点で文書化されている上限として扱い、容量の目標や恒久的な契約とはみなさないでください。リリース前に、アカウントとワークロードについて公式ページを再確認します。メッセージ数だけでなく、To、Cc、Bcc、再試行、ファンアウトを含めた受信者数を計算してください。アプリケーションレベルのレート、同時実行数、キューの滞留時間、テナント間の公平性の制御を、Googleの上限よりも低く設定します。増加の加速と残りの余裕についてアラートを出します。上限に達したときに、許可されていないアカウントにトラフィックを分散したり、エンベロープ送信者をローテーションしたり、管理されていない接続を開いたりして対処しないでください。共有のWorkspaceの境界に定期的に近づくワークロードには、専用の転送手段の評価が必要かもしれません。

耐久性のあるサブミッションのワークフローを構築する

SMTPクライアントは、認可されたサーバーのワーカーまたはキューの背後に置きます。安定したビジネスイベントのキー、テナント、メッセージの種類、テンプレートのリビジョン、承認済みの送信者と受信者、同意または必要性の根拠、サプレッションの判断、試行履歴を含む送信ジョブを1つ保存します。そのジョブを一度だけ取得し、内容をレンダリングしてバリデーションしてから、設定済みのGoogleのエンドポイントに接続します。トランザクションあたりの受信者数とメッセージのサイズは、現在の上限とプロダクトのポリシーに従って制限します。完全なSMTP応答、拡張ステータスコード、リモートホスト、タイムスタンプ、試行の識別子を記録し、認証情報や不要な内容はログに残さないでください。リレーがDATAトランザクションを受け付けた場合、記録するのはプロバイダーまたはリレーによる受け付けの段階だけです。データを送信したあと、最終的な応答を確認する前にクライアントがタイムアウトした場合は、その試行を不明のままにして、再送する前に突き合わせてください。SMTPにはアプリケーションの冪等キーがないため、重複の制御はプロダクトのキューとイベントモデルが担います。

すべてを再試行するのではなくリレーのエラーを分類する

GoogleのSMTPリレーのエラーページには、メールのリレーの拒否、無効なリレーの認証情報またはドメインの識別、1日の上限の超過、ピーク時の上限による一時的な遅延、1つのトランザクションでの受信者数の超過など、それぞれ異なる状況が記載されています。正確な応答を記録し、社内の限定されたクラスに対応づけてください。設定、送信者ドメイン、認証情報、IPアドレス、トランザクションあたりの受信者数のエラーは、再実行する前に修正します。1日の上限に達したら、作業を一時停止するか、スケジュールし直します。対象となる一時的なピーク時のエラーや転送のエラーは、指数バックオフ、ジッター、試行回数の上限、キューの滞留時間の上限を設けて再試行します。恒久的な応答を無期限に再試行しないでください。エラーで未登録のIPアドレスが示された場合は、許可リストを広げるのではなく、実行環境の実際の公開の送信元アドレスとWorkspaceの正しい設定を確認してください。送信元システム、設定のリビジョン、送信者ドメイン、ステータスのクラス、時刻ごとに、プライバシーに配慮した最小限の集計数を保持します。見たことのない応答や認証の急増は、ポリシーのずれ、認証情報の失効、NATの変更、不正利用を示している可能性があるため、アラートを出してください。

リレーへのアクセスとは別に送信者を認証する

Googleのリレーを使う許可は、受信者から見た送信者の認証と同じではありません。エンベロープのIDについて実際の送信経路を許可するSPFポリシーを公開し、組織が管理しDMARCとアライメントするドメインでDKIM署名を設定し、表示されるFromドメインにレビュー済みのDMARCポリシーを公開してください。管理された外部のメールボックスで、受信した生のメッセージを検証します。SPFの結果とドメイン、DKIMの結果、d=ドメインとセレクター、表示されるFromドメイン、アライメント、DMARCの結果を記録します。技術的に有効なプロバイダーやWorkspaceの署名であっても、独自のFromドメインとはアライメントしていないことがあります。転送によってSPFの証拠が変わることもあります。1つのテストをパスさせるためだけに、2つ目のSPFレコードを追加したり、組織全体でDMARCを弱めたりしないでください。DNSとメールの管理者と連携し、変更前のレコードを保存し、権威サーバーとキャッシュリゾルバーの応答をテストし、IDの変更は1つずつ展開してください。

オブザーバビリティとテスト済みの離脱手順を求める

Google管理コンソールのメールログ検索や、利用できる場合はリレー側のログを使いますが、判断の基準となるシステムはプロダクトが所有する送信台帳にしてください。メッセージの種類と送信者ドメインごとに、キューの滞留時間、受け付け、一時的な応答と恒久的な応答、上限の使用状況、バウンスと苦情のシグナル、認証、レイテンシーを監視します。アクセスを制限し、日常的な指標には完全なアドレスや内容を含めないようにします。送信元IPアドレスの変更、認証情報のローテーション、TLSの失敗、管理コンソールの設定の無効化、ユーザーの停止、上限への到達、受信者のファンアウト、DNSの変更、プロバイダーの障害をテストします。耐久性のあるジョブを失わずに、影響を受けたグループを一時停止できるロールバックを定義してください。移行に備えて、プロバイダー固有のSMTPのフィールドを1つのアダプターに分離し、ビジネスイベントのキー、サプレッションの状態、送信者の認可、試行履歴を保持します。2つ目のリレーが、恒久的なポリシー上の拒否や受信者による拒否を自動的に回避する手段になってはいけません。互換性を確保するには、ホスト名を変えるだけでなく、フィールド単位とエラー単位のテストが必要です。

SendHQの位置付け

SendHQは、想定されたプロダクトコミュニケーション向けのワークスペース単位のメールAPIで、検証済みドメイン送信、メール受信、ホスト型テンプレート、配信イベント、サプレッション、Webダッシュボードを備えています。アカウントとテナントの境界、認証情報とローテーション、送信者の許可に関する制御、エンベロープと表示されるID、TLSの失敗、受信者上限、一時的および恒久的な応答、曖昧な結果、サプレッション、イベントの読み戻し、移行について、最新のドキュメントと管理されたテストを通じてGoogle Workspace SMTP relayと比較してください。

よくある質問

Google WorkspaceのSMTPリレーではどのホスト名を使いますか？

Googleの現在の設定ガイドでは smtp-relay.gmail.com を使います。ポートとTLSの挙動は、公式の手順と、組織で適用しているセキュリティポリシーに従って選択してください。

GoogleのSMTPリレーは送信元IPアドレスで制限できますか？

はい。管理コンソールの設定で、指定した公開IPアドレスからの接続だけを受け付けることができます。範囲は狭く保ち、実行環境の実際の送信元アドレスとフェイルオーバー時の挙動を確認してください。

このリレーでは、TLSなしでSMTP認証は使えますか？

Googleの現在のガイドでは、SMTP認証にはTLSが必要とされています。本番のクライアントは、必要なTLSのネゴシエーションや証明書の検証が成功しなかった場合、安全側に倒して失敗させるべきです。

1回のSMTPリレーのトランザクションに含められる受信者は何人までですか？

Googleは現在、smtp-relay.gmail.com のトランザクションあたり100人の受信者の上限を文書化しています。プロバイダーの上限やアカウントの条件は変わることがあるため、最新の公式ページを再確認してください。

ピーク時のリレー上限のエラーは再試行すべきですか？

Googleは、ピーク時の上限への到達を一時的なものとしています。すぐにファンアウトするのではなく、同じ耐久性のあるジョブを保持し、上限を設けたバックオフ、ジッター、試行回数の上限、キューの滞留時間の上限を使ってください。

リレーが受け付ければ、受信者にメールが届いたことになりますか？

いいえ。リレーによる受け付けは、転送の1つの段階にすぎません。受信サーバーによる受け付け、後からのバウンス、メールボックスでのフィルタリング、受信トレイへの到達、人による反応は、それぞれ別の観測結果です。

Googleのリレーへのアクセスで、SPF、DKIM、DMARCの代わりになりますか？

いいえ。リレーの認可が制御するのは、Googleのサービスの利用です。受信者から見た送信ドメイン認証とDMARCのアライメントには、正しい送信者ID、DNSレコード、署名、そして受信したメッセージでの検証が必要です。

このページは、SendHQがGoogleのSMTPリレーと互換性があることを証明していますか？

いいえ。SendHQの文書化された機能をGoogle Workspace SMTP relayの要件と比較し、認証、TLS、クォータ、エラー、配信イベントの読み戻しについて管理されたテストを使用してください。

出典

さらに学ぶ

SMTPリレーサービスの評価方法サブミッションのセキュリティ、認証、キュー、再試行の挙動、上限、配信イベント、サプレッション、分離、移行への適合性の観点から、SMTPリレーサービスを評価します。SMTPメールプロトコル：アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションメールのワークフローをどう形作るかを解説します。SMTPポート25、465、587の実践ガイド役割とTLSモードに応じて適切なSMTPポートを選び、接続、ハンドシェイク、認証、メッセージの受け付けの失敗を診断します。メール到達率サービスの評価方法対象範囲、証拠、認証、フィードバックループ、サプレッション、プライバシー、ポータビリティ、運用への適合性の観点から、メール到達率サービスを評価します。Gmail APIの実装ガイド：プロダクトチーム向け最小権限のOAuth、耐久性のあるメールボックス同期、安全な送信、上限を設けた再試行、明確なサービスアカウントのモデルで、Gmail APIへのアクセスを実装する方法を解説します。