用語 · Amazon SES

Amazon SESとは何か、アプリケーションのメールにどう影響するのか

Amazon Simple Email Service（Amazon SES）は、APIまたはSMTPインターフェースを通じたメール送信とメール受信のためのAWSインフラです。アプリケーションチームにとってSESを選ぶことは、送信呼び出しだけでなく、検証済み送信者ID、リージョン設定、IAM権限、クォータ処理、メッセージ作成、イベント取り込み、バウンスと苦情への対応、サプレッション、運用監視を担うことを意味します。SESに受け付けられたことはAWSが配信を試行することを意味しますが、受信トレイ到達率を証明するものではありません。SESはより大きなアプリケーションメールシステム内の転送およびフィードバック層として扱ってください。

サービスの守備範囲を理解する

SESはAWS APIまたはSMTPエンドポイントを通じてアプリケーションメールを受け付け、構造化フィールドからMIMEメッセージを組み立てることも、送信者が組み立てたメッセージを受け付けることもできます。つまり、これは完全なプロダクトワークフローではなくインフラです。誰が送信できるか、どのテナントがドメインを所有するか、テンプレートと受信者データをどう扱うか、いつ再試行が安全か、リクエスト成功後にユーザーに何を表示するかは、引き続きアプリケーションが決定します。有用なアーキテクチャでは3つの状態を分離します。アプリケーションがジョブを受け付けた状態、SESがメッセージを受け付けた状態、受信メールサーバーがメッセージを受け付けた、または拒否した状態です。これらの状態は異なる時点で生じ、異なるIDを必要とします。Webhookの再試行やサポート調査を、件名や受信者データから推測せずに照合できるよう、独自の不変のジョブIDをSESメッセージIDとともに保存してください。

送信前にIDを検証する

AWSは、SESで使用するドメインまたはメールアドレスを検証済みIDと定義しています。送信前に、From、Source、Sender、Return-PathのIDがSESの検証ルールを満たしている必要があります。アプリケーションにとっては、通常はドメイン検証が長く使える選択です。そのドメイン配下のアドレスを承認でき、ドメイン単位の認証にも対応しているからです。検証は、すべてのデプロイにコピーできる一度きりのチェックボックスではありません。IDのステータスとEasy DKIMの設定はリージョン単位であるため、あるAWSリージョンで検証済みのドメインが別のリージョンで自動的に使えるわけではありません。オンボーディングはステートマシンとして構築してください。IDをリクエストし、正確なDNSレコードを表示し、権威あるプロバイダーのステータスをポーリングし、選択したリージョンが成功を報告してから初めて本番送信を許可します。DNSを別の送信サービスと共有している場合は既存のSPFとDMARCのポリシーをそのまま保ち、手軽さのために2つ目のSPFレコードを作ってはいけません。

リージョンをメール設定の一部にする

SESのリソースと運用上の上限はリージョン単位です。検証済みID、サンドボックスの状態、1日あたりのクォータ、最大送信レート、Easy DKIMの設定、サプレッションの設定、フィードバックの送信先は、リージョンによって異なる場合があります。AWSで有効な認証情報があっても、IDを別のSESエンドポイントに持ち運べるわけではありません。リージョンは汎用の環境デフォルトに隠さず、設定の中でプロバイダーのアカウントやIDと並べて明示してください。フェイルオーバーに備えて、インシデントが起きる前にセカンダリリージョンを準備しておきます。IDを検証し、DKIMレコードを公開し、本番アクセスと適切なクォータを取得し、イベントの送信先を設定し、メッセージ識別子とWebhookの処理をテストし、サプレッションの挙動を理解していることを確認します。そうしなければ、障害中にエンドポイントだけを切り替えても、ひとつのインシデントが検証エラー、スロットリング、フィードバックの欠落という別のインシデントに置き換わるだけです。

APIとSMTPは意図をもって選ぶ

AWSは、SES APIとSMTPインターフェースのどちらによる本番送信にも対応しています。APIは、すでにAWSの認証とSDKを使っているアプリケーションに適しており、構造化メッセージとrawメッセージの両方の操作を提供します。SMTPは、すでにSMTPで通信するソフトウェアに適していますが、SESのSMTP認証情報は通常のAWSアクセスキーとは別物で、しかもリージョン単位です。どちらを選んでも、キュー、冪等性、タイムアウトへの対応、安全な再試行ルールが不要になるわけではありません。アプリケーションがレスポンスを受け取る前に接続が失敗しても、プロバイダーはメッセージを受け付けている可能性があります。ユーザーからのリクエストを、新しいアプリケーション識別子で闇雲に再試行するのは避けてください。キューへの投入は1回にとどめ、得られた場合はプロバイダーのレスポンスを保持し、ワーカーには安定したジョブを再試行させます。rawメッセージの操作は正確なMIMEの制御が必要な場合にのみ使い、メッセージをSESに渡す前にヘッダーと行の長さを検証してください。

サンドボックスとクォータを実行時の制約として扱う

新しいSESアカウントとリージョンの組み合わせはサンドボックス内にある場合があります。AWSは現在、サンドボックスの上限として24時間あたり200件の受信者への配信と毎秒1通を文書化しており、メールボックスシミュレーターを除いて送信は検証済み受信者に制限されています。本番のクォータはアカウント、リージョン、承認されたユースケースによって異なります。クォータはAPIリクエストではなく受信者を数えるため、10人の受信者宛ての1リクエストは10単位を消費します。アクティブなリージョンごとに実際のクォータを確認し、ローリング方式の1日あたりの送信枠と送信レートの両方を考慮してバックプレッシャーを設計してください。プロバイダーによるスロットリングでは、キューに入ったジョブを遅延させるべきであり、重複送信を作成したり、説明のない成功として表面化させたりしてはいけません。ローンチ前に本番アクセスと現実的な上限を申請し、管理された受信者で負荷テストを実施してください。サンドボックスを無料枠として説明してはならず、あるリージョンでの承認が別のリージョンにも適用されると想定しないでください。

配信状態はイベントから組み立てる

SESの送信操作が成功したということは、リクエストが受け付けられ、SESが配信を試みるという意味です。受信者がメッセージを開封した、受信トレイで見た、あるいは受信サーバーがメッセージを受け付けたという意味ですらありません。SESのイベント発行では、送信、配信、バウンス、苦情、拒否、レンダリング失敗、遅延、購読、開封、クリックを、設定したAWSの送信先に通知できます。運用上重要な違いは、配信イベントは受信者のメールサーバーによる受け付けを表すのに対し、バウンスと苦情のイベントにはポリシーに基づく対応が必要だという点です。配信システムは通知を再試行することがあるため、イベントは冪等に取り込んでください。プロバイダーのメッセージ識別子とイベント時刻を保持し、不正な形式のWebhookペイロードは拒否し、可能な限り状態遷移が逆戻りしないようにします。開封とクリックの観測は任意のエンゲージメントシグナルであり、プライバシーやクライアントによる制約があります。これらによって、送信経路上の配信が行われたかどうかの判断を変えるべきではありません。

バウンス、苦情、サプレッションに対応する

既知の不正な受信者や受信を望まない受信者をサプレッションリストに追加することは、ユーザーと送信アカウントの両方を守ります。AWSは、グローバル、アカウント単位、設定セット単位、そして新しいテナント単位のサプレッションを提供していますが、正確な適用範囲は設定とリージョンによって異なります。それでも、アプリケーションには明確な受信者ポリシーが必要です。恒久的にバウンスしたアドレスへの定常的な再試行は止め、苦情があれば直ちにサプレッションリストに追加し、リストからの削除には、アドレスが有効で受信者がメールを予期しているという根拠を求めるべきです。マルチテナントのプロダクトでは、サプレッションを共有すると、あるテナントでの結果が別のテナントの送信に影響することがあるため、顧客のオンボーディングの前に、サプレッションをアカウント全体で共有するか、テナントごとに分離するかを決めておいてください。生のアドレスは一般的な分析やログに含めないようにしましょう。運用システムではサプレッションを適用するためにアドレスが必要な場合がありますが、ダッシュボードや実験では集計値や仮名化した指標を使うべきです。

最小権限を適用し、テナントを分離する

IAMポリシーでは、プリンシパルが呼び出せるSESの操作を制限し、送信アクションについてFrom、受信者、Return-Pathのアドレスを制約できます。送信承認ポリシーは別の問題を解決するものです。IDの所有者が検証済みIDの使用を委任でき、その委任を個別に取り消せます。単一のアプリケーションであれば、ワークロードが実際に必要とする送信と監視のアクションだけを持つプリンシパルを使いましょう。WebブラウザにAWSの認証情報を渡してはいけません。マルチテナントのメールプロダクトでは、共有のSESアカウントがワークスペースのモデルを自動的に理解してくれるわけではないため、アプリケーション層での認可も必要です。SESに送信する前に、認証済みのテナントが検証済みのFromドメインを所有していることを確認し、APIキーとメッセージの記録をそのテナントにスコープし、他テナントの識別子を指定しても何もデータが返らないようにしてください。プロバイダーのIAMとアプリケーションの認可は補完し合う制御であり、どちらかでもう一方を代替することはできません。

本番運用前のチェックリストを使う

ローンチ前に、AWSアカウント、リージョン、IDのARN、検証ステータス、DKIMのステータス、サンドボックスの状態、1日あたりのクォータ、最大送信レート、イベントの送信先、サプレッションの適用範囲、認証情報の担当者を記録してください。通常の配信、メールボックスシミュレーターでのバウンス、対応している場合は苦情のテスト、スロットリングのレスポンス、イベントの再試行、送信後のプロバイダーのタイムアウトを実際に試します。キューのワーカーが安定したジョブを重複させないこと、配信イベントが正しいメッセージを更新すること、恒久的なバウンスによって以降の定常的な送信が止まることを確認してください。拒否されたリクエスト、スロットリング、イベント取り込みの失敗、バウンスと苦情の変化、クォータの余裕についてアラームを設定します。新しいリージョン、ドメイン、テナントの種類、メッセージの種類を導入するたびに設定を見直してください。このチェックリストによって、SESは隠れた依存関係から、担当者がいて失敗モードを観測できる明示的なサブシステムに変わります。

SendHQの位置付けを判断する

AWSネイティブの制御を求め、周辺のアプリケーション層を自分たちで構築する用意があるチームは、SESを直接組み込めます。SendHQは、検証済みの送信ドメイン、スコープ付きのAPIキー、単発送信と一括送信、受信用のインボックス、配信イベントへのアクセス、サプレッションのワークフローを備えた、範囲を絞ったワークスペース単位のメール契約を提供します。公開APIでは、Fromドメインがワークスペースに属し、かつ検証済みであることが求められ、受け付けたメッセージは後から確認できるよう記録されます。このプロダクト層は、SESのID、クォータ、レピュテーション、受信側のフィルタリングのルールに取って代わるものではありません。2つの層は分けて評価してください。プロバイダーはメールを送信して報告し、アプリケーション層はテナントの所有権を強制し、安定したリソースを提供し、運用状態を提示します。SESを直接使う場合もSendHQも受信トレイへの到達を保証するものではないため、どちらも制御、オブザーバビリティ、運用の担当、アプリケーションのワークフローへの適合性で評価してください。

よくある質問

Amazon SESはメールAPIですか、それともSMTPサーバーですか？

HTTPS APIとSMTPインターフェースの両方を提供しています。アプリケーションの認証方式とメッセージ作成の要件に応じて選び、キュー、安定したジョブ識別子、イベント処理、サプレッションは送信呼び出しの外側に置いてください。

Amazon SESを使うにはドメインの検証が必要ですか？

From、Source、Sender、Return-Pathのアドレスとして使うIDは、それぞれ検証する必要があります。限られたケースではメールアドレスのIDでも対応できますが、アプリケーションが管理するアドレスやDKIMには、一般にドメイン検証のほうが実用的です。

SESの成功レスポンスは、メールが配信されたことを意味しますか？

いいえ。SESがリクエストを受け付け、配信を試みるという意味です。その後の配信イベントは受信者のメールサーバーがメッセージを受け付けたことを意味しますが、どちらの状態も、メッセージが受信トレイのフォルダに届いたことを証明するものではありません。

Amazon SESのクォータはリージョン間で共有されますか？

いいえ。AWSのドキュメントでは、送信クォータ、サンドボックスの状態、検証済みID、DKIMの設定、サプレッションの設定はリージョン単位とされています。インシデント中にエンドポイントを切り替えるのではなく、本番トラフィックを受ける可能性のあるすべてのリージョンを事前に準備してテストしてください。

SESで送信した後、アプリケーションは何を保存すべきですか？

安定したアプリケーションのジョブID、受け付けられた場合はSESのメッセージ識別子、プロバイダーとリージョン、現在の状態、タイムスタンプ、正規化された配信イベントを保存してください。メッセージの内容と受信者データは、広範なログや分析に含めないようにします。

SESを直接使う代わりにSendHQを使うべきなのはどんなときですか？

AWSとの連携と周辺のすべての制御を自分たちで担いたい場合は、SESを直接使ってください。ワークスペース単位のキー、ドメイン所有権のチェック、受信用のインボックス、メッセージのリソース、配信イベント、サプレッションのワークフローがアプリケーションの基本要素として役立つ場合は、SendHQを検討してください。

出典

さらに学ぶ

Amazon SESの料金：プロダクトチームのためのコストモデル受信者数、データ量、料金プラン、専用IP、イベント基盤、クォータ、そして配信を取り巻くエンジニアリング層まで含めて、Amazon SESのコストをモデル化します。