Amazon SES - メール送受信サービス

SESとは何か

Amazon SES（Simple Email Service）は、AWS が提供するフルマネージド型のメール送受信サービスです。アプリケーションから直接メール送信や受信処理を実行でき、大規模なメール配信でも安定して動作するスケーラブルな構成を実現します。

基本的な仕組み

SES は以下の3つの主要機能を提供します：

1. メール送信：アプリケーションから HTTP REST API または SMTP エンドポイント経由でメール送信
2. メール受信：SES が受信したメールをトリガーに S3、Lambda、SNS などへ自動的に処理を振り分け
3. バウンス・苦情処理：配信に失敗したメールや受信者からの苦情を管理し、リスト品質を維持

SES は マネージド型のため、メールサーバーのセットアップや保守が不要で、AWS のインフラ上でスケーラブルにメール配信を運用できます。

フルマネージド型とサーバーレス型の位置づけ

• インフラ管理不要：メールサーバーの構築・保守が不要
• 自動スケーリング：送信量増加に自動的に対応
• コスト効率：使用した分だけ課金（送信メール数、受信バイト数）
• AWS サービス連携：Lambda、SNS、SQS、CloudWatch などとシームレスに統合

AWS メッセージングサービスの比較と使い分け

AWS はメッセージング機能を提供する複数のサービスを提供しており、用途に応じた選択が重要です。SES、SNS、SQS の違いは試験頻出の論点です。

SES vs SNS vs SQS の比較表

特性	SES	SNS	SQS
主要な用途	メール送受信	プッシュ型通知	ポーリング型キューイング
通信モデル	非同期送受信	Pub/Sub（パブリッシャー→複数サブスクライバー）	ポーリング型（コンシューマーが主動的に取得）
配信方式	送信者が指定した受信者へ直接配信	複数の通信プロトコル（Email、SMS、HTTP、SQS など）への一斉配信	コンシューマーがメッセージをキューから取得
メッセージ永続性	配信後は保持されない	配信後は保持されない	保持期間中（デフォルト4日間）はキューに保持
受信側の独立性	送受信者が独立	プッシュ配信のため受信側の状態に影響されにくい	高い（ポーリング型でコンシューマーのペースで処理）
データ量制限	最大256KB/メール	最大256KB/メッセージ	標準 256KB、拡張クライアントで最大 2GB
順序保証	標準では保証なし	標準では保証なし（FIFO トピックで保証可能）	標準では保証なし（FIFO キューで保証可能）

ユースケース別の選択基準

SES を選ぶべきケース

• トランザクションメール：注文確認、パスワードリセット、領収書などの自動送信
• マーケティングメール：ニュースレター、キャンペーン通知など大量配信
• カスタマーサポート：自動返信や受信メールの処理・分類
• 内部通知：アラート、レポートメール

SNS を選ぶべきケース

• 複数チャネルへの一斉通知：Email、SMS、HTTP、モバイルプッシュなど複数プロトコルに同時配信
• リアルタイム通知：イベント発生直後に複数の受信者へ即座に通知
• ファンアウト構成：1つのイベントから複数のサービス（Lambda、SQS など）をトリガー
• Pub/Sub パターン：パブリッシャーと複数のサブスクライバーが疎結合

SQS を選ぶべきケース

• タスク処理の並列実行：複数のワーカーで非同期処理
• バックプレッシャー対策：送信側が受信側の処理能力に合わせた調整が不要
• メッセージの永続化：一時的な処理遅延に対応したメッセージ蓄積
• 順序保証が必須：FIFO キューで厳密な実行順序を確保

組み合わせパターン（重要）

SAA 試験では複数のサービスを組み合わせたアーキテクチャがよく出題されます：

• SQS → Lambda → SES：キューのメッセージを Lambda で処理してメール送信（バッチ処理的な非同期メール送信）
• SNS → SQS ファンアウト → 複数の Lambda：SNS のパブリッシュをトリガーに複数の処理を並列実行
• SNS → SQS → Lambda → SES：通知 → キューイング → カスタム処理 → メール送信
• EventBridge → SES：定時実行や複雑なイベントルーティングでメール送信

SESのメール送信方法

SES でメール送信する方法は、アプリケーションの統合方法や既存インフラとの互換性に応じて2つの方式から選択します。

HTTP REST API による送信

SendEmail API

シンプルなメール送信に最適化された API です：

パラメータ: From, To, Subject, Body (テキスト/HTML)
→ SES が自動的にメッセージを構成して送信

特徴：

• 最もシンプルな使用方法
• From、To、Subject、Body を指定するだけ
• CC、BCC、Reply-To も指定可能
• HTML メール対応
• AWS SDK（Boto3、SDK for JavaScript など）から直接呼び出し可能

認証：AWS アクセスキー＋シークレットアクセスキーを使用

用途：通常のアプリケーション統合、AWS Lambda からの送信

SendRawEmail API

完全な MIME フォーマットのメッセージを指定して送信します：

パラメータ: 完全な MIME フォーマット（RFC 5322 準拠）
→ SES はメッセージを検証して送信

特徴：

• メッセージ全体をアプリケーション側で構成
• 複雑なメールヘッダー、添付ファイル、署名など完全制御可能
• S3 から取得したメッセージもそのまま送信可能
• カスタムヘッダーの追加が容易

用途：メールクライアント、メール処理システムからの統合、カスタムメッセージ構成

API 送信の認証と権限制御

• 認証方式：AWS アクセスキー＋シークレットアクセスキー
• IAM ポリシー：ses:SendEmail と ses:SendRawEmail パーミッションで権限制御
• 暗号化：API 呼び出しは HTTPS で暗号化（TLS 1.2 以上）

SMTP エンドポイント による送信

既存のメールクライアントライブラリや従来のメールシステムとの統合に対応：

SMTP エンドポイント の基本

• エンドポイント形式：email-smtp.ap-northeast-1.amazonaws.com など（リージョン固有）
• 利用ポート：
  • 25 — スタンダードポート（ポート制限がある場合が多い）
  • 465 — SMTP over SSL（暗号化通信推奨）
  • 587 — Message Submission（TLS での暗黙的な暗号化、推奨）
• TLS（Transport Layer Security）が必須
• 認証：専用 IAM ユーザーのクレデンシャル（SMTP 用 username/password）

SMTP ユーザーの設定方法

IAM コンソールで SMTP 用のユーザーを作成し、次の情報を取得：

1. SMTP username（AKIA... などの形式）
2. SMTP password（生成時のみ表示）
3. エンドポイント情報

既存のメールライブラリ（Python の smtplib、Node.js の nodemailer など）にこれらの認証情報を設定して使用：

# Python 例
import smtplib
server = smtplib.SMTP('email-smtp.ap-northeast-1.amazonaws.com', 587)
server.starttls()
server.login(smtp_username, smtp_password)
server.send_message(message)

SMTP 送信の特徴

メリット：

• 既存のメールインフラとの統合が容易
• メールライブラリの既存コードをそのまま使用可能
• レガシーアプリケーションの最小限の変更で対応

デメリット：

• API 送信より低レベルでの制御が必要
• ポート制限のあるネットワークでは 465/587 の選択が重要
• エラー処理がプロトコルレベル

API vs SMTP エンドポイント の選択基準

判断基準	HTTP REST API	SMTP エンドポイント
AWS SDK との親和性	高い（推奨）	低い（標準ライブラリ）
アプリケーション統合	モダンなアプリ（Lambda など）	レガシーシステム
ポート制限への対応	問題なし（HTTPS 443）	25/465/587 の制約
セットアップ手間	少ない（AWS キー設定のみ）	中程度（SMTP ユーザー作成）
エラーハンドリング	AWS SDK の例外処理	SMTP プロトコルエラー処理
大規模メール配信	効率的（バッチ、非同期 API）	接続管理が複雑

SESのメール受信と連携パターン

SES はメール受信機能も提供し、受信したメールをトリガーに AWS サービスへの自動処理を実現します。これはイベント駆動アーキテクチャの重要なパターンです。

メール受信の基本フロー

受信メール → SES の受信ルール → アクション（S3/Lambda/SNS）

1. SES が指定したドメイン宛のメールを受信
2. 受信ルールセットで条件に基づいてメールを分類
3. マッチしたルールのアクションに従って自動処理を実行

アクション先の比較：S3 vs Lambda vs SNS

S3 バケットへの保存

受信メール全文を S3 に保存するアクション：

用途：

• メールのアーカイブ：監査、コンプライアンス要件
• ログ保存：メール配信履歴の長期保存
• インポート処理：後での一括処理用に S3 に蓄積

特徴：

• メッセージ全文（MIME 形式）が S3 オブジェクトとして保存
• オブジェクトキー形式：指定したプレフィックス + メッセージ ID
• 長期保存コスト が低い（S3 標準ストレージ、あるいは Glacier へライフサイクル遷移）
• メタデータ（To アドレス、送信時刻など）を S3 オブジェクトタグとして付与可能

例：

s3://my-bucket/emails/2026/05/15/message-12345.eml

Lambda 関数の呼び出し

受信メールを Lambda 関数のイベントとしてトリガー：

用途：

• 自動返信：受信メールの From アドレスに対する自動返信メール送信
• メール解析・分類：受信メールの内容に基づいた分類、ルーティング
• 添付ファイル処理：添付ファイルの抽出、検疫、ウイルススキャン
• データ抽出：メール本文から構造化データの抽出、DynamoDB への登録

特徴：

• Lambda 関数がメール内容にアクセス可能（S3 から取得）
• カスタムコードで複雑な処理を実装
• 実行時間、CPU、メモリに制限あり（Lambda の標準制限）
• コードで外部 API 呼び出しも可能

例：カスタマーサポートメール自動分類

受信メール（support@example.com）
→ Lambda で送信者分類、チケット作成
→ DynamoDB に登録
→ 該当チームへ通知

SNS トピックへの発行

受信メール情報を SNS に発行し、複数の受信者へ通知：

用途：

• 複数チャネルへの一斉通知：受信メール情報を Email、SMS、HTTP など複数の受信者に同時配信
• ファンアウト構成：1つの受信メールから複数の処理（Lambda、SQS など）をトリガー
• チーム間の通知：特定のメールアドレス宛のメールを複数のチームに即座に通知

特徴：

• SNS トピックに受信メール情報が発行される
• SNS の Pub/Sub メカニズムで複数の受信者に配信
• 複数プロトコル対応（Email、SMS、HTTP、SQS サブスクリプション など）

例：インシデント報告メールの複数チャネル通知

受信メール（alerts@example.com）
→ SNS トピック「Incidents」に発行
→ 複数の受信者：
   - Email サブスクリプション → 管理者にメール
   - SQS サブスクリプション → チケット管理システムへ
   - Lambda サブスクリプション → 自動分析・対応

ユースケース別の選択ガイド

ユースケース	選択	理由
受信メールのアーカイブ・監査	S3	メール全文の長期保存、低コスト
自動返信、添付ファイル処理	Lambda	カスタム処理、ファイル操作
受信メール情報の複数チャネル通知	SNS	Pub/Sub、複数の受信者
カスタマーサポートメールの自動分類	Lambda + DynamoDB	分類ロジック、チケット作成
特定メール発生時の大量メール送信	Lambda → SQS → Lambda → SES	非同期、バッチ処理
複数部門への即座な通知	SNS + Email/SMS	リアルタイム、複数通知先

受信ルールセットの設定

受信ルールセットで条件に基づいてメールを処理：

条件の例：

• To アドレス：support@example.com 宛のメール
• From パターン：特定ドメインからのメール
• Subject キーワード：特定の単語を含むメール
• 受信者アドレス：複数の To アドレス条件

アクション：複数指定可能（順序執行）

• S3 に保存 → その後 Lambda を呼び出し（同じメールを両方で処理）
• SNS に発行 → SNS のサブスクリプション先で並列処理

SES 利用準備とドメイン管理

SES を本格的に運用するには、初期設定とドメイン検証が必須です。試験では Sandbox モードと本番環境の違いが出題されます。

ドメイン検証

SES を使用する前に、メール送信に使用するドメインを AWS に検証する必要があります：

検証プロセス：

1. AWS コンソール SES で「Verified Identities」にドメインを追加
2. AWS が指定した DNS レコード（CNAME など）をドメイン DNS に設定
3. SES が DNS 検証を実行（数分～数時間で完了）
4. 検証完了後、そのドメイン宛のメール送信が可能に

個別メールアドレスの検証：

• Sandbox モード中は、From/To アドレスをすべて個別検証する必要がある場合があります

Sandbox モード vs 本番環境

Sandbox モード（初期状態）

制限事項：

• 送信できるアドレス：AWS で事前検証したアドレスのみ
• 受信できるアドレス：AWS で事前検証したアドレスのみ
• 送信レート制限：1秒あたり最大1メール、24時間以内に最大200メール
• 用途：開発・テスト環境での動作確認

特徴：

• ドメイン検証さえあれば、コストをかけずにテスト可能
• 本番デプロイ前の動作確認に最適

本番環境（Sandbox から卒業）

AWSサポートへの申請手順：

1. AWS Support コンソールから「Sending Limits」の引き上げリクエストを作成
2. 申請内容：
   • メール送信の用途（トランザクション、マーケティング など）
   • 見込み送信量
   • メール受信者の同意取得方法
3. AWS が審査（通常 1～2 営業日）
4. 承認後、制限が解除

本番環境での制限解除後：

• 検証済みドメイン宛なら任意のアドレスに送信可能
• 送信レート制限が大幅に引き上げ（数千～数万メール/秒 等、申請内容に基づいて決定）
• 24時間送信メール数の制限なし

重要：本番環境では SES の送信評価（Reputation）が重要になります。

メール認証（SPF/DKIM/DMARC）

大規模メール送信では認証プロトコルの設定が必須です：

SPF（Sender Policy Framework）

• DNS の TXT レコードで「このドメインからのメールを送信する許可サーバー」を指定
• SES の SMTP IP アドレスを SPF レコードに含める

DKIM（DomainKeys Identified Mail）

• SES が自動的に秘密鍵を生成
• メッセージに DKIM 署名を追加
• 受信者が署名を検証して送信元の真正性を確認

DMARC（Domain-based Message Authentication, Reporting & Conformance）

• SPF/DKIM の結果に基づいたポリシー指定
• 認証失敗時のアクション（reject、quarantine など）定義
• レポート受信

SAA 試験での位置づけ：

• SPF/DKIM の設定が、大規模メール配信の信頼性向上に必要なこと
• 認証設定なしでは受信側で迷惑メール扱いされるリスク

送信評価（Reputation）の管理

大規模メール送信時、SES が送信者の評価を監視：

• バウンスレート：メール送信失敗の割合
• 苦情レート：受信者からの苦情（spam 報告）の割合
• 一時的な送信停止：評価が低下した場合、送信が一時停止される可能性

リスク回避方法：

• 正確なメーリングリストの管理（無効なアドレスを削除）
• 購読者の同意取得（opt-in）
• バウンス処理の実装

バウンス処理と配信品質管理

SES のメール送信が失敗した場合、バウンス通知を適切に処理することで、メーリングリストの品質を維持します。

バウンス タイプ

ハードバウンス（Permanent Failures）

原因：

• メールアドレスが存在しない
• ドメインが存在しない
• 受信者が明示的に拒否

対応：

• 即座にメーリングリストから削除
• 以降のメール送信対象から外す
• リスト品質を維持

ソフトバウンス（Transient Failures）

原因：

• メールボックスの容量満杯
• メールサーバーの一時的なダウン
• ネットワーク接続の一時的な問題

対応：

• 一時的なエラーとして記録
• 一定期間後に再試行
• 複数回失敗後にハードバウンス扱いへ

バウンス通知

SES がメール送受信の失敗を検知した場合、SNS トピック経由で通知：

通知内容：

• バウンスメールアドレス
• バウンスタイプ（Hard/Soft）
• バウンス発生時刻
• メッセージ ID

処理フロー：

SES がバウンスを検知
→ SNS トピックに通知メッセージを発行
→ SNS サブスクリプション（Lambda など）で受信
→ Lambda 関数がハードバウンス判定
→ DynamoDB 等でメーリングリスト更新

苦情処理（Complaint Handling）

受信者が「迷惑メール」と報告した場合の処理：

SNS 経由で通知：

• 苦情を報告したメールアドレス
• 苦情発生時刻

対応：

• 即座にメーリングリストから削除（ハードバウンス同様）
• 苦情率が高い場合、SES の送信が制限される可能性

CloudWatch でのモニタリング

SES は送信メトリクスを CloudWatch に出力：

• Send：送信メール数
• Bounce：バウンス数
• Complaint：苦情数
• Reject：拒否数
• Delivery：配信成功数
• Open（オプション有効化時）：メール開封数
• Click（オプション有効化時）：リンククリック数

アラーム設定：

Bounce Rate > 5% → 警告アラーム
Complaint Rate > 0.1% → 送信停止アラーム

SES のセキュリティとアクセス制御

SES の送受信機能を安全に運用するためのセキュリティ実装が重要です。

IAM ポリシーによる権限制御

SES の各機能に対して細粒度のパーミッションを設定可能：

主要なアクション：

• ses:SendEmail — SendEmail API の使用
• ses:SendRawEmail — SendRawEmail API の使用
• ses:VerifyEmailIdentity — メールアドレス検証
• ses:VerifyDomainIdentity — ドメイン検証
• ses:ListVerifiedEmailAddresses — 検証済みアドレスの表示

ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ses:SendEmail", "ses:SendRawEmail"],
      "Resource": "arn:aws:ses:ap-northeast-1:123456789:*"
    }
  ]
}

SMTP ユーザーの認証管理

SMTP エンドポイント用に専用 IAM ユーザーを作成し、SMTP クレデンシャルを発行：

セキュリティ実装：

• 本番環境では専用ユーザーを作成（共有ユーザーを避ける）
• SMTP パスワードは環境変数 or シークレット管理ツール（AWS Secrets Manager など）で保管
• アクセスログを CloudTrail で監視

VPC エンドポイント経由のアクセス

PrivateLink を使用した VPC エンドポイント経由での SES アクセス：

メリット：

• VPC 内からのプライベートアクセス：インターネット経由の通信が不要
• セキュリティ向上：NAT Gateway の費用削減、インターネットゲートウェイ不要
• コンプライアンス：データが AWS ネットワーク内に留まる

送信承認ポリシー（Cross-Account Sending）

アカウント A の SES から アカウント B のドメインでメール送信を許可する場合、ドメイン所有者が送信承認ポリシーを設定：

用途：

• マルチテナント SaaS でのメール配信
• 複数 AWS アカウント管理の場合の中央集約

SAA 試験でのポイント まとめ

SES は SAA-C03 試験で頻出のサービスです。特に以下の論点を理解しておくことが重要です。

試験頻出の選択問題

1. メッセージングサービスの選択問題

シナリオ：「顧客に注文確認メールを自動送信する必要があります。最適なサービスは？」

判断基準：

• メール送信 → SES
• 複数の通知プロトコル（Email/SMS 同時） → SNS
• タスク処理の非同期実行 → SQS

よくある誤り：

• SNS で OK と誤解（SNS はメール送信専門ではなく通知サービス）
• SQS で OK と誤解（SQS はキューイングでメール送信機能なし）

2. メール送信方法の選択問題

シナリオ：「既存の SMTP メールクライアントライブラリを使用する必要があります。SES との統合方法は？」

判断基準：

• SMTP ライブラリ使用 → SMTP エンドポイント
• AWS SDK 利用 → HTTP REST API
• ポート制限環境 → 465 (SMTP over SSL) または 587 (Message Submission)

3. メール受信アクション選択問題

シナリオ：「カスタマーサポートメールを受信し、複数のチーム（Email、Slack、チケットシステム）に即座に通知する必要があります。」

判断基準：

• 複数チャネルへの通知 → SNS（Pub/Sub で複数プロトコル対応）
• メール全文のアーカイブ → S3
• カスタム処理（自動返信、分類） → Lambda

4. Sandbox モード vs 本番環境問題

シナリオ：「SES で任意のメールアドレスに送信したいが、制限があります。」

判断基準：

• Sandbox モード中 → 検証済みアドレスのみ
• 本番環境 → AWS Support に申請が必要
• 送信レート制限 → Sandbox は 200 メール/24時間、本番は申請内容に基づいて決定

5. 疎結合アーキテクチャでの位置づけ

シナリオ：「注文処理から複数の非同期タスク（メール送信、インベントリ更新、分析ログ記録）を実行する必要があります。」

適切な構成：

注文受信 → SNS トピック（Pub/Sub）
  ├─ SQS キュー → Lambda → SES（メール送信）
  ├─ SQS キュー → Lambda → DynamoDB（インベントリ更新）
  └─ SQS キュー → Lambda → S3（ログ記録）

ポイント：

• SNS で複数の疎結合なワーカーをトリガー
• 各ワーカーが独立して失敗しない
• スケーラビリティと耐障害性が高い

その他の重要ポイント

• 認証：SPF/DKIM/DMARC の設定が大規模メール配信の信頼性向上に必要
• バウンス処理：ハードバウンスはメーリングリストから即座に削除
• 送信評価：バウンスレート・苦情レートの監視が重要
• IAM ポリシー：送信権限を最小限に制限（最小権限の原則）
• VPC エンドポイント：プライベートなメール送信にはエンドポイント経由が有効

参考リンク

AWS SES 公式ドキュメント SES ユーザーガイド - メール送信 SES ユーザーガイド - メール受信