--- title: "Amazon SESとは｜メール送信の仕組み・SMTP/API・サンドボックス解除と料金を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15600/" published: 2026-07-24 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon SESとは｜メール送信の仕組み・SMTP/API・サンドボックス解除と料金を実装者目線で解説 Amazon SES（Simple Email Service／シンプル イーメール サービス）は、AWSが提供するマネージドなメール送受信サービスです。自前でメールサーバー（MTA）を立てて運用する代わりに、SESのAPIかSMTPエンドポイントへリクエストを投げるだけで、アプリケーションからメールを送れます。この記事で扱うのは、SES v2 APIとSMTPという2つの送信経路とそのまま実行できるコード、EメールアドレスIDとドメインIDの検証、送信を絞る「サンドボックス」とその解除、DKIM・SPF・DMARCによる送信ドメイン認証、バウンスと苦情の監視、1,000通0.10ドルの従量課金と月額プラン、そしていつSESを選び、いつ別方式へ寄せるかの判断です。SQS・SNSとの比較は別記事に譲り、SESで何ができ、どう組み、いくらかかるかに絞ります。 ## まとめ：SESはアプリからメールを送るためのマネージドな送信基盤 先に結論を示します。Amazon SESは、アプリケーションからのメール送信をサーバー管理なしで担う、従量課金のメール送信基盤です。パスワードリセットや注文確認のようなトランザクションメール、ニュースレターのようなマーケティングメールのどちらも送れ、送った通数分だけ課金されます。到達性（受信箱に届く割合）を左右するIPアドレスの評価や送信ドメイン認証、バウンス処理といった、メール配信でつまずきやすい部分をSES側の仕組みで支えられる点が実務上の利点になります。 向くのは、Webサービスや業務システムからプログラムでメールを送りたい、送信量が増減するので固定費より従量課金にしたい、というケースです。逆に、営業担当が画面上でリストを選んで配信する運用や、開封率をもとにしたシナリオ配信のような機能が要るなら、SES単体ではなくマーケティングオートメーション（MA）ツールのほうが素直に収まります。まずSESで送れるかを起点に考え、配信管理のGUIやシナリオ機能が要るなら上位のツールへ寄せる、という順序が現実的でしょう。 実装の最短経路は3手です。第1に送信元のドメインIDを作ってEasy DKIMのCNAMEをDNSへ公開し、第2に`aws sesv2 put-account-details`で本番アクセスを申請してサンドボックスを外し、第3に設定セットを1つ作ってバウンスと苦情のイベント送信先を紐づけます。この3手を踏まないまま送り始めると、1日200通の壁か、バウンス率5%の壁のどちらかで必ず止まりました。以降の章では、この3手をコードと実額つきで順にたどります。 ## SESの基本｜マネージドなメール送受信サービスと2つの送信経路 SESを理解する近道は、「メールを送る/受ける口を貸してくれるサービス」と捉え、その口が2種類あることをつかむことです。ここでは全体像から入ります。 ### Amazon SESとは何か｜メールサーバーを持たずに送受信する仕組み Amazon SESは、メールの送信と受信を代行するマネージドサービスです。送信では、アプリがSESにメールの内容と宛先を渡すと、SESが受信側のメールサーバーへ配送し、届かなかった場合のバウンスや、受信者が迷惑メール報告した場合の苦情（コンプレイント）を通知として返します。受信では、独自ドメイン宛のメールをSESで受け取り、S3への保存やLambdaの起動といった処理につなげられます。自前でPostfixなどのMTAを構築・運用し、IPの評価を維持し、認証や監視を作り込む手間を、SES側の仕組みへ肩代わりさせられるのが本質です。SESはSQSやSNSと名前が似ていますが役割が異なり、3サービスの違いと使い分けは[AWS SQS・SNS・SESの違いと使い分けの解説](https://www.issoh.co.jp/tech/details/9310/)で整理しています。自前でMTAを立てる側の設計と工数を先に知りたい場合は、[メール配信システムの自作・構築の解説](https://www.issoh.co.jp/tech/details/15331/)と読み比べると、SESに寄せて省ける範囲がはっきりします。 細かい制限は先に把握しておくと設計が楽になります。[AWS公式のサービスクォータ](https://docs.aws.amazon.com/ses/latest/dg/quotas.html)によると、1メッセージの最大サイズはSES v1 APIが10MB、SES v2 APIとSMTPが40MB（いずれもbase64エンコード後）で、1メッセージあたりの宛先は「To・Cc・Bcc」を合わせて50件までです（2026年9月時点）。検証できるID数は1リージョンあたり10,000件、設定セットは10,000件、設定セットあたりのイベント送信先は10件までとされています。10MBを超えるメッセージは帯域のスロットリング対象になる旨も明記されているため、大きな添付を前提にした設計は避けたほうが無難です。 ### SES APIとSMTPインターフェースという2つの送信経路の使い分け SESへメールを渡す経路は2つあります。1つはSES API（v2のHTTPS API）で、AWS SDKからプログラムで呼び出す方式です。もう1つはSMTPインターフェースで、SESが提供するSMTPエンドポイントとSMTP認証情報を使い、既存のメール送信ライブラリやアプリケーションの設定を差し替えるだけで送れます。目安として、新規にアプリを実装するならSDK経由のAPIが型付きで扱いやすく、すでにSMTPで送っている既存システムやSMTPしか話せないソフトからの移行ならSMTPインターフェースが手戻りを抑えられます。どちらの経路でも、送信元アドレスの権限管理に使うのはIAMです。SES APIを叩くIAMユーザーやロールに送信許可のポリシーを付与する設計になり、権限設計の考え方は[AWS IAMとはの解説](https://www.issoh.co.jp/tech/details/15427/)が参考になります。 機能差も選定の材料になります。[SES API v2のSendEmail](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API%5FSendEmail.html)は`POST`で`v2/email/outbound-emails`を呼ぶ操作で、本文の指定方法として組み立て済みの`Simple`、MIMEを自分で組む`Raw`、テンプレートに値を差し込む`Template`の3形式を持ちます。加えて、送信イベントに任意のラベルを付ける`EmailTags`、マルチリージョン送信の`EndpointId`、テナントを指定する`TenantName`といったパラメータがAPI側にしかありません。集計軸を自分で切りたい、テナント単位で評価を分けたい、という要件があるならAPI経路を選ぶことになります。 ## 送信を始める準備｜送信元IDの検証とサンドボックスの解除申請 SESは、なりすまし送信や大量の迷惑メールを防ぐため、使い始めに2つの関門を設けています。送信元の検証と、サンドボックスからの脱出です。 ### EメールアドレスIDとドメインIDという2種類の送信元IDの検証 SESで送信するには、送信元として使うアドレスかドメインをあらかじめ「ID（アイデンティティ）」として検証しておく必要があります。検証には2種類あり、EメールアドレスIDは特定の1アドレス（例：no-reply@example.com）だけを確認する方式で、届いた確認メールのリンクを踏めば完了します。ドメインIDはドメイン全体（例：example.com）を確認する方式で、DNSに指定のレコードを登録して所有を証明する仕組みです。実務では、ドメインIDを検証しておけば、そのドメイン配下の任意のアドレスを送信元に使えるため、複数のFromアドレスを扱うシステムではドメイン単位の検証が扱いやすくなります。後述するDKIM認証もドメイン単位で設定するため、本番運用はドメインIDを基本に据えるのが定石です。 手順の実測値を押さえておきます。[AWS公式のID作成手順](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html)では、EメールアドレスIDの確認メールは作成から5分以内に届き、そのリンクは24時間で失効すると明記されています。ドメインIDのほうはEasy DKIMのCNAMEを3本公開する方式で、DNSの伝播に最大72時間かかる前提です。ドメイン名は大文字小文字を区別しませんが、メールアドレスは区別する点に注意してください。なお、ドメインから検証を継承しただけのアドレスは単純な送信しかできず、設定セットの割り当てや委任送信の認可といった踏み込んだ使い方をするなら、そのアドレス自体も明示的に検証する必要があります。DNSをAWS側に寄せているなら、CNAMEの発行先は[Amazon Route 53とはの解説](https://www.issoh.co.jp/tech/details/15471/)で扱っているホストゾーンになります。 ### サンドボックスの1日200通制限を外す本番アクセスの申請手順 新規に作ったSESアカウントは、リージョンごとに「サンドボックス」という制限状態から始まります。[AWS公式の本番アクセス手順](https://docs.aws.amazon.com/ses/latest/dg/request-production-access.html)によると、サンドボックス中は送信先が検証済みのアドレス/ドメインかメールボックスシミュレータ宛に限られ、送信量は24時間あたり200通まで、送信レートは1秒あたり1通までに絞られます（2026年9月時点）。さらに、アカウントレベルの抑制リストに対する一括操作とAPI呼び出しも無効化されるため、抑制リストの運用検証はサンドボックスのままでは通し切れません。 実際の顧客へ送るには、この制限を外す「本番アクセス（production access）」をリクエストします。コンソールの場合は「Account dashboard」から「Request production access」を開き、メール種別（MarketingかTransactional）、WebサイトのURL、連絡先アドレス（カンマ区切りで最大4件）、希望言語（EnglishかJapanese）、そしてバウンス・苦情への対応体制があることの確認にチェックを入れて送信します。同じ内容は[AWS CLIのsesv2 put-account-details](https://docs.aws.amazon.com/cli/latest/reference/sesv2/put-account-details.html)でも投げられ、複数IDやセットアップ自動化のときはこちらが速いでしょう。 ``` aws sesv2 put-account-details \ --production-access-enabled \ --mail-type TRANSACTIONAL \ --website-url https://example.com \ --additional-contact-email-addresses ops@example.com \ --contact-language JA ``` 申請を出すと、審査が終わるまでアカウント詳細は編集できなくなります。AWSサポートは初回の応答を24時間以内に返す運用で、内容に問題がなければその24時間の枠内で本番アクセスが付与され、追加情報が必要な場合だけ長引きます。開発初期はサンドボックスのまま検証用アドレスでテストし、リリース前に本番申請を通す、という段取りが安全です。EC2から25番ポートで送る構成にしているなら、EC2側のポート25スロットル解除も別途申請しておく必要があります。 ## コードで送る｜SES v2 APIとSMTPの実装手順とハマりどころ ここからは実際に1通送るところまで進めます。APIとSMTPの両方を、そのまま貼って動かせる形で置きます。 ### boto3でSES v2のSendEmailを呼び1通目を送るまでのコード APIから送る場合、SDKのクライアント名はSES v1の`ses`ではなく`sesv2`です。ここを間違えると、40MBのメッセージサイズやテナント指定といったv2側の仕様に乗れません。以下はboto3から東京リージョンのSESでテキストメールを1通送る最小構成で、設定セットとイベントタグまで付けています。 ``` import boto3 ses = boto3.client("sesv2", region_name="ap-northeast-1") resp = ses.send_email( FromEmailAddress="no-reply@example.com", Destination={"ToAddresses": ["user@example.com"]}, Content={ "Simple": { "Subject": {"Data": "パスワード再設定のご案内", "Charset": "UTF-8"}, "Body": { "Text": {"Data": "24時間以内に手続きを完了してください。", "Charset": "UTF-8"} }, } }, ConfigurationSetName="txmail", EmailTags=[{"Name": "purpose", "Value": "password-reset"}], ) print(resp["MessageId"]) ``` 返る`MessageId`は「SESが受け付けた」ことの証明であって、「受信箱に届いた」ことの証明ではありません。AWS公式のAPIリファレンスにも、ウイルスを含む添付や不正なテンプレート差し込みのように、受け付けたのに送信されない場合がある旨が書かれています。到達の確認は、次章のイベント送信先で`DELIVERY`や`BOUNCE`を受けて行ってください。エラーでは、サンドボックスのままなら`MessageRejected`、MAIL FROMドメインの検証漏れなら`MailFromDomainNotVerifiedException`、送信停止中なら`SendingPausedException`が返り、いずれもHTTP 400です。送信レート超過だけは`TooManyRequestsException`のHTTP 429なので、指数バックオフで再試行する分岐をこの1点だけ分けて実装します。 ### SMTPエンドポイントに接続してPythonから1通送るまでの設定 SMTP経路のホスト名は`email-smtp.＜リージョン＞.amazonaws.com`の形です。[AWS公式のSMTP接続ドキュメント](https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html)では、接続の暗号化が必須で、STARTTLSなら25番・587番・2587番、TLS Wrapper（SMTPS）なら465番・2465番を使うと定められています。EC2は既定で25番の送信をスロットルするため、EC2から送るなら587番を選ぶか、スロットル解除を申請するか、VPCエンドポイントを使うかの三択になります。認証に使うのはIAMのアクセスキーそのものではなく、IAMユーザーから生成したSMTPユーザー名とSMTPパスワードです。 ``` import smtplib import ssl from email.message import EmailMessage msg = EmailMessage() msg["From"] = "no-reply@example.com" msg["To"] = "user@example.com" msg["Subject"] = "ご注文を受け付けました" msg.set_content("注文番号 A-1024 の受付が完了しました。") ctx = ssl.create_default_context() with smtplib.SMTP("email-smtp.ap-northeast-1.amazonaws.com", 587) as s: s.starttls(context=ctx) s.login("AKIAEXAMPLESMTPUSER", "SMTP専用のパスワード") s.send_message(msg) ``` 移行時にはまりやすいのは、送信レートの単位がコネクション数ではなく「1秒あたりのメッセージ数」である点です。既存アプリが1コネクションで大量に流し込む作りだと、本番アクセス取得後もレート超過で弾かれます。もう1つは、SMTP経路では設定セットをコード引数で渡せないため、IDに既定の設定セットを割り当てるか、`X-SES-CONFIGURATION-SET`ヘッダーを付けて指定する必要がある点です。既存の送信基盤をSESへ寄せ替える案件では、この2点の改修見積もりを先に立てておくと後戻りが減ります。 ### IAMポリシーで送信元アドレスを絞る最小権限のJSONの書き方 SESの権限を`ses:SendEmail`だけで開けてしまうと、そのIAMロールを持つコードは検証済みの全アドレスを名乗れます。誤送信や乗っ取り時の被害を絞るなら、リソースをIDのARNに限定し、さらに`ses:FromAddress`条件キーでFromアドレスまで固定するのが実務的です。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ses:SendEmail"], "Resource": "arn:aws:ses:ap-northeast-1:123456789012:identity/example.com", "Condition": { "StringEquals": { "ses:FromAddress": "no-reply@example.com" } } } ] } ``` AWS公式のレピュテーション関連ドキュメントは、意図しない送信の原因として「IAMアクセスキーの漏えい」と「SMTPパスワードの漏えい」を名指ししており、IAMユーザーのアクセスキーではなく一時認証情報へ寄せることを勧めています。Lambdaやコンテナから送るならロールを付与し、キーを配らない構成にしてください。ロールとポリシーの切り分け方は[AWS IAMとはの解説](https://www.issoh.co.jp/tech/details/15427/)にまとめています。 ## 到達性を支える認証と評価｜DKIM・SPF・DMARCとレピュテーション 送れることと、受信箱まで届くことは別問題です。到達性を左右する送信ドメイン認証と、送信者の評価（レピュテーション）を押さえます。 ### Easy DKIM・SPF・DMARCで送信ドメイン認証を3点そろえる 受信側のメールサーバーは、送信元が正規のものかを認証技術で判定します。SESには、これらの認証設定を支援するための仕組みがあるのです。DKIMは、メールに電子署名を付けて改ざんと送信元を検証する技術で、[AWS公式のEasy DKIMドキュメント](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim-easy.html)によれば、有効にするとSESが既定で2048ビットの署名鍵を全メールに付与し、DNSにCNAMEを3本登録するだけで鍵の管理をSESへ任せられます。DNSプロバイダの都合で1024ビットへ落とすことも選べますが、鍵長の切り替えは24時間に1回までという制限があるため、最初に決め切ってしまうほうが事故が少ないでしょう。自前の鍵を持ち込むBYODKIMでは、1024ビット以上2048ビット以下のRSA鍵をPEMで渡します。 SPFは、そのドメインの送信を許可されたサーバーかをDNSで示す仕組みで、SESでは[カスタムMAIL FROMドメイン](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html)を設定してSPFを揃えます。MXレコードが見つからないときの挙動として「既定のMAIL FROMドメインへフォールバック」と「メッセージを拒否」のどちらかを選ぶ設計になっており、認証を厳格に運用するなら拒否側を選びます。レコードの具体的な書き方は[SPFとはの解説](https://www.issoh.co.jp/column/details/13466/)が詳しいです。DMARCは、DKIMとSPFの結果をもとに認証失敗時の扱いを宣言するポリシーで、none・quarantine・rejectのどれを置くかで防御力が変わります。この3段階の選び方は[DMARCの仕組みの解説](https://www.issoh.co.jp/tech/details/12267/)で整理しました。GmailやYahoo!などの主要受信側がドメイン認証を送信者へ求める流れが強まっており、本番運用ではEasy DKIMを有効化し、SPF・DMARCまで揃えることが到達性の前提になります。 ### バウンス率5%・苦情率0.1%を境に送信が止まる仕組みと監視 SESは、送信者ごとの評価（レピュテーション）を監視し、バウンス率と苦情率が高い送信者を制限します。バウンスとは宛先不達のことで、苦情とは受信者による迷惑メール報告のことです。[AWS公式のレピュテーション指標のドキュメント](https://docs.aws.amazon.com/ses/latest/dg/reputationdashboardmessages.html)には具体的な数値が書かれており、バウンス率は5%未満に保つのが推奨で、5%以上になると自動でアカウントが審査（under review）に入り、10%以上では送信が停止される場合があります。苦情率は0.1%未満が推奨で、0.1%以上で審査、0.5%以上で停止という段階です（2026年9月時点）。 計算の対象にも注意が必要です。バウンス率に数えるのはハードバウンス（存在しないアドレス）だけで、一時的な不達のソフトバウンス、検証済みアドレス宛のバウンス、メールボックスシミュレータ宛の結果は除外されます。また、率はアカウントごとの「代表的な送信量」に対して計算され、その母数は送信パターンに応じて変動する、というのが明記された計算条件です。したがって「昨日1万通送ってバウンス3件だから0.03%」といった自前の計算と、コンソールの表示は一致しないことがあります。数字は必ずレピュテーション指標のページかCloudWatchのメトリクスで確認してください。 ### 設定セットにイベント送信先を作りバウンスを抑制リストへ反映する バウンスと苦情を人が目で追う運用は続きません。[設定セット](https://docs.aws.amazon.com/ses/latest/dg/using-configuration-sets.html)を1つ作り、そこへ[イベント送信先](https://docs.aws.amazon.com/ses/latest/dg/monitor-using-event-publishing.html)を紐づけると、送信・配信・バウンス・苦情・開封・クリックといったイベントをSNSトピックやCloudWatch、Kinesis Data Firehose、EventBridgeへ流せます。以下はSNSトピックへバウンスと苦情と拒否を流す設定です。 ``` aws sesv2 create-configuration-set --configuration-set-name txmail aws sesv2 create-configuration-set-event-destination \ --configuration-set-name txmail \ --event-destination-name bounce-to-sns \ --event-destination Enabled=true,MatchingEventTypes=BOUNCE,COMPLAINT,REJECT,SnsDestination={TopicArn=arn:aws:sns:ap-northeast-1:123456789012:ses-events} ``` 受け取ったイベントの行き先として、まず押さえておきたいのが[アカウントレベルの抑制リスト](https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list.html)です。ハードバウンスや苦情を出したアドレスをここへ入れておくと、以降そのアドレスへの送信をSES側で止められます。無効アドレスを送信前に洗い出す万能な方法は無いので、送信結果を抑制リストへ反映し続ける運用を作り込むほうが堅実でしょう。通知の振り分けには[Amazon EventBridgeとはの解説](https://www.issoh.co.jp/tech/details/15513/)、受けた処理の実行には[AWS Lambdaとはの解説](https://www.issoh.co.jp/tech/details/15407/)が組み合わせの参考になります。トピック側の配信先やフィルタリングの設計は[Amazon SNSとはの解説](https://www.issoh.co.jp/tech/details/15612/)を合わせて読むと決めやすいです。なお、メールボックスシミュレータへの送信は評価には効きませんが、料金は通常の送信と同じレートで発生します。 ## 料金と構成｜従量課金の体系と専用IP・配信性能を高める構成要素 SESは送った量で課金される従量制です。何にいくらかかるかの骨格と、到達性を底上げする構成要素を整理します。 ### 1,000通0.10ドルの従量課金と3つの月額プランという2体系 2026年9月時点の[AWS公式の料金ページ](https://aws.amazon.com/ses/pricing/)では、料金体系は、次の2本立てという構成です。1本目が個別課金（à la carte）で、送信・受信ともに1,000通あたり0.10ドル、送信メールの添付データは1GBあたり0.12ドル、受信では別途1,000チャンクあたり0.09ドルが加わります。2本目が月額プランで、月1,000万通までの単価はEssentialsが1,000通0.16ドル、Proが0.22ドル、Enterpriseが0.23ドル、これに加えてProはアカウント・リージョンごとに月105ドル、Enterpriseは月500ドルの固定費がかかります。単価は通数の帯ごとに段階的に適用され、帯を超えた分だけ安い単価になる方式です。 ここは見落としが起きやすい変更点です。料金ページの注記によると、新規のSESアカウント、および2025年6月1日以降に課金対象の利用が無いアカウントとリージョンの組み合わせは、2026年7月21日からEssentialsプラン開始になります。つまり、これから作るアカウントの既定は1,000通0.10ドルではなく0.16ドルで、個別課金へ切り替えたい場合は、自分でプランを変更する操作が必要です。新規のAWS顧客には最大200ドルのFree Tierクレジット（12か月有効）が用意されている点も、初期の試算では効いてきます。他社SaaSと並べて比べるなら、円建て価格まで踏み込んだ[SendGrid料金の実額と落とし穴の解説](https://www.issoh.co.jp/tech/details/17343/)が比較材料になります。 ### 月10万通と月500万通で月額がどう変わるかを試算して比べる 単価だけでは判断しにくいので、送信のみ・添付なし・オプション無しという条件で単純化した月額を並べます。Proの列には固定費105ドルを含めました。 | 月間通数 | 個別課金 | Essentials | Pro（固定費込み） | | ----- | -------- | ---------- | ---------- | | 10万通 | 10.00ドル | 16.00ドル | 127.00ドル | | 100万通 | 100.00ドル | 160.00ドル | 325.00ドル | | 500万通 | 500.00ドル | 800.00ドル | 1,205.00ドル | この試算から読めるのは、通数が増えても個別課金と月額プランの差は縮まらず、むしろ広がるということです。プランを選ぶ理由は単価ではなく、Virtual Deliverability Managerのグローバル配信、Managedな専用IP、メールアドレス検証、マルチリージョン送信といった機能が標準で付くかどうかにあります。個別課金でこれらを個別に足すと、たとえばVDMのSES配信が1,000通0.07ドル、Managedな専用IPが月15ドルに1,000通0.08ドルという具合に積み上がるため、使う機能が3つを超えるあたりからプラン側が有利になります。 ### 設定セット・専用IP・Virtual Deliverability Managerの役割 到達性と運用を支える構成要素も押さえておきます。設定セットは、送信のグループごとにイベント送信先や後述のIP、送信レートの上限などをまとめて管理する単位です。IPアドレスには共有IPと[専用IP（Dedicated IP）](https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip.html)があり、Managedは月15ドルに通数課金（月1,000万通まで1,000通0.08ドル）、Standardと持ち込み（BYOIP）は1IPあたり月24.95ドルです。BYOIPは最小256アドレスからという制約があり、最小構成でも月6,387.20ドルになる点は先に共有しておくべき数字でしょう。専用IPプールは、Managedとstandardを合わせて50個までです。 [Virtual Deliverability Manager（VDM）](https://docs.aws.amazon.com/ses/latest/dg/vdm.html)は、到達性の指標や改善提案を提供する機能で、SES配信は1,000通0.07ドルから、クエリは1,000件0.0005ドル（月5,000件まで無料）、グローバル配信は月1,250ドルという体系です。小〜中規模の送信では共有IPと設定セットの基本構成で足り、送信量が増え評価を自社で管理したい段階で専用IPやVDMを足す、という順序で考えると過剰投資を避けられます。なお、テナント機能を使うと送信元をテナント単位で分離して評価を切り分けられ、1アカウント1リージョンあたり1,000テナントまでが標準で含まれます。 ## Amazon SESを採用すべき条件と見送って別方式に寄せる場面 ここは言い切ります。SESはすべてのメール用途で正解になるわけではありません。向く条件と、あえて選ばない場面を分けて示します。 ### SESの採用が向く条件｜アプリからのトランザクション大量送信 効果が出るのは、Webサービスやモバイルアプリ、業務システムからプログラムでメールを送りたいケースです。会員登録の確認、パスワードリセット、注文通知といったトランザクションメールや、配信基盤を自前で持ちたい大量のメール配信で、サーバー管理なしに従量課金で送れます。SMTPインターフェースを備えるため、既存システムの送信先をSESへ差し替える移行もしやすく、AWS上に基盤があるならLambdaやSQSと組み合わせた非同期の送信パイプラインも組めるでしょう。AWS上でメール送信基盤を設計・実装したい、既存のメール送信をSESへ移行して到達性と運用を立て直したい、といった相談は[AWSを含むインフラ構築の受託](https://www.issoh.co.jp/service/system/aws/)で受け付けています。認証設計から監視・運用までを外部に任せたい場合の入口です。 ### 見送るべき場面｜GUIでの配信管理やシナリオ機能が要るケース 逆に見送ったほうがよい場面もあります。営業やマーケティング担当が管理画面でリストを作り、テンプレートを選んで配信し、開封・クリックをもとにシナリオを分岐させる、といった運用が主目的なら、SES単体では画面や機能が足りず、MAツールやメール配信サービスのほうが素直です（それらの内部でSESを配信エンジンに使う構成もあります）。また、送信量がごく少なく、既存のGmailやMicrosoft 365のSMTPで十分に間に合うなら、SESを導入する手間に見合わないこともあるでしょう。判断の順序としては、まずプログラムからの送信が中心か・配信管理のGUIが要るかを見極め、GUIやシナリオが主なら上位ツールへ、プログラム送信が主ならSESへ寄せる、という進め方が堅実です。 ## よくある質問 SESの送信準備や料金など、導入前に迷いやすい点をまとめます。 ### Amazon SESとSMTPサーバーを自前で立てるのは何が違いますか？ 自前のSMTPサーバー（MTA）は、サーバーの構築・運用に加え、IPアドレスの評価維持、DKIM/SPF/DMARCの設定、バウンス処理や監視をすべて自分で作り込む必要があります。SESはこれらをマネージドサービスとして肩代わりし、APIかSMTP経由でメールを渡すだけで送れます。到達性を左右する部分をSES側の仕組みで支えられるのが大きな違いです。 ### SESのサンドボックスはどうやって解除しますか？ コンソールのアカウントダッシュボード、またはAWS CLIの`put-account-details`コマンドから本番アクセスをリクエストします。メール種別、WebサイトのURL、連絡先（最大4件）、希望言語、バウンス・苦情への対応体制の確認を申告すると、AWSサポートが24時間以内に初回応答を返す運用です。承認されると、検証済み以外の宛先へも送れるようになります。 ### SESの料金はどのくらいですか？ 個別課金では、送信・受信ともに1,000通あたり0.10ドル、添付データは1GBあたり0.12ドルが基本です（2026年9月時点）。月額プランは月1,000万通までEssentialsが0.16ドル、Proが0.22ドル＋月105ドル、Enterpriseが0.23ドル＋月500ドルという段階になります。新規アカウントは2026年7月21日からEssentials開始が既定なので、個別課金にしたい場合は自分で切り替えてください。 ### SESとSNSはメール送信でどう使い分けますか？ SNSでもメール通知は送れますが、宛先はSNSトピックの購読者に限られ、通知用途の簡易なテキストが中心です。顧客向けにHTMLメールを差出人やドメインを整えて大量に送るなら、送信に特化したSESが向きます。トピックの配信先やフィルタリングの設計は[Amazon SNSとはの解説](https://www.issoh.co.jp/tech/details/15612/)が詳しく、3サービスの役割差は[SQS・SNS・SESの違いの解説](https://www.issoh.co.jp/tech/details/9310/)で比較しました。 ### DKIMやSPFは必ず設定しないといけませんか？ 技術的にはEasy DKIMを有効にしなくても送信自体は可能ですが、GmailやYahoo!など主要な受信側がドメイン認証を送信者へ求める流れが強まっているため、本番運用ではEasy DKIMを有効化し、SPF・DMARCまで揃えるのが前提です。認証が不十分だと迷惑メール扱いされ、受信箱に届かない割合が増えます。 ### Amazon Pinpointのメール機能からSESへ移行する必要はありますか？ はい、メール送信機能の移行は必要です。[AWS公式のPinpointサポート終了の案内](https://docs.aws.amazon.com/pinpoint/latest/userguide/migrate.html)では、2026年10月30日にサポートが終了し、以降はコンソールやエンドポイント・セグメント・キャンペーン・ジャーニーへアクセスできなくなるとされています。メール送信の移行先としてSESが案内されており、配信品質ダッシュボードに相当する機能はVDMが担います。移行の判断材料は[Amazon Pinpointとはの解説](https://www.issoh.co.jp/tech/details/15602/)にまとめました。 ### SES v2 APIとSMTPはどちらで実装するのが有利ですか？ 新規実装ならAPIです。`EmailTags`による集計軸の付与、テナント指定、マルチリージョンのエンドポイント指定はAPI側にしかありません。既存システムの送信先を差し替えるだけならSMTPが速く、その場合は設定セットを既定として割り当てるか、`X-SES-CONFIGURATION-SET`ヘッダーで指定します。1メッセージの上限はv2 APIとSMTPがともに40MB、v1 APIだけが10MBです。 ## 関連記事 - [AWS SQS・SNS・SESの違いと使い分け｜3サービスの選定基準を比較](https://www.issoh.co.jp/tech/details/9310/)：SESを含むメッセージング3サービスの役割差と、どれをいつ選ぶかの判断基準を比較で整理しています。 - [Amazon SNSとは｜Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断](https://www.issoh.co.jp/tech/details/15612/)：SESのイベント送信先として使うSNSトピックの設計と、通知用途との切り分けがわかります。 - [Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装](https://www.issoh.co.jp/tech/details/15513/)：バウンスや苦情のイベントを振り分けて後続処理へつなぐ、イベント駆動連携の考え方がわかります。 - [AWS Lambdaとは｜仕組み・料金体系とコールドスタート対策・採用判断](https://www.issoh.co.jp/tech/details/15407/)：SESのイベントを受けたバウンス処理や、受信メールの処理をサーバーレスで組む際の土台になります。 - [メール配信システムの自作・構築とは？SMTP基盤設計と到達率確保の実装手順](https://www.issoh.co.jp/tech/details/15331/)：SESに寄せずに自前でMTAを組む場合の設計と工数が把握でき、比較の土台になります。 - [SendGrid料金の実額と落とし穴｜Freeプラン終了後の円建てプランと代替比較](https://www.issoh.co.jp/tech/details/17343/)：他社のメール送信SaaSと円建てで比べるときの、単価と固定費の見方がわかります。 --- 出典: [Amazon SESとは｜メール送信の仕組み・SMTP/API・サンドボックス解除と料金を実装者目線で解説]()（株式会社一創）