Amazon SESのアカウント停止はなぜ起こる？原因・解除方法・再発防止策を解説

ある日突然、Amazon SES（Simple Email Service）から「アカウントのEメール送信機能を一時停止しました」という通知が届く。会員登録の完了メールも、パスワード再設定メールも、購入確認メールも一斉に止まり、問い合わせが殺到する。Amazon SESを本番運用しているシステム担当者にとって、これは最も避けたい事態のひとつです。

しかし、アカウント停止は前触れなく起こるわけではありません。バウンス率や苦情率といった明確な「数値の基準」を超えたとき、Amazon SESは送信者全体の評価を守るために、段階的にアカウントを制限していきます。つまり、仕組みを正しく理解していれば、停止は予防でき、万が一停止されても正しい手順で解除できます。

この記事では、まず「レビュー（審査中）」と「送信一時停止」の違いを整理したうえで、停止の原因となる具体的な数値基準、解除までのステップ、サポートケースへの返信例、そして二度と繰り返さないための予防策までを、実務目線で体系的に解説します。

Amazon SESの「アカウント停止」とは？まず状態を正しく理解する

「アカウント停止」と一口に言っても、Amazon SESには複数の状態があります。ここを混同すると、対応の優先順位を誤ります。最初に状態の正しい理解から始めましょう。

「レビュー（審査中）」と「送信一時停止」は別物

Amazon SESの送信制限には、大きく分けて2つの段階があります。

ひとつが「レビュー（審査中／Under review）」です。これは、バウンスや苦情などの指標が基準を超え、アカウントが監視対象になった状態を指します。送信を行うアカウントが審査中の場合も、Amazon SES経由でメールを送信することはできます。ただし、審査の原因となった問題を解決し、問題が再発しないように対策を講じる必要があります。

もうひとつが「送信一時停止（Sending paused）」です。こちらはより深刻な状態で、アカウントのメール送信機能が一時停止された場合、問題を解決するまでAmazon SESを使用してメールを送信することはできません。

レビューはいわば「イエローカード」、送信一時停止は「レッドカード」に近いものと考えると整理しやすいでしょう。レビュー期間中に問題を解決できなければ、停止へと移行します。

レピュテーションダッシュボードで確認できる4つのステータス

自社アカウントが今どの状態にあるかは、Amazon SESコンソールの「アカウントダッシュボード（評価メトリクス）」で確認できます。表示されるステータスは主に次の4段階です。

ステータス	状態	送信可否
Healthy	正常	送信可能
Under review（レビュー中）	指標が基準を超え監視対象	送信可能（要対策）
Pending sending pause（送信一時停止保留中）	停止される可能性がある	送信可能（猶予期間）
Sending paused（送信一時停止）	送信機能が停止	送信不可

「Pending sending pause（送信一時停止保留中）」は、メトリクスによりアカウントがレビューされており、このレビューの原因となった問題が解決していない状態です。この問題により、アカウントのEメール送信機能が一時停止される可能性があります。

なぜAmazon SESがここまで厳格なのか。その理由は送信インフラの構造にあります。Amazon SESアカウントは、デフォルトでは他のユーザーと共有されているIPアドレスセットを使用します（オプションで専有IPの利用も可能です）。共有IPアドレスのレピュテーションを保護するために、アカウントから新たにメールを送信する機能が一時停止されることがあります。一社の不適切な送信が、同じIPを使う他社の到達率まで巻き込んで悪化させるため、Amazon SES側が予防的に止めるのです。

Amazon SESがアカウント停止になる主な原因

アカウント停止につながる問題は、明確に数値化されています。代表的な原因は「バウンス率」「苦情率」「スパムトラップ」「ポリシー違反」の4つ。それぞれの基準を正確に押さえましょう。

バウンス率の超過

バウンスとは、宛先不明などで送信メールが届かず、送信者に返ってくる現象です。無効なアドレスへの送信が多いほどバウンス率は上がります。

基準は明確です。バウンス率が5%以上になると、アカウントはレビュー対象になります。バウンス率が10%以上の場合は、高いバウンス率の原因となった問題が解決するまで、以後のEメール送信を一時停止することがあります。

公式にはバウンス率を5%未満、苦情率を0.1%未満に維持することがおすすめされています。運用上は、レビュー対象になる前に手を打てるよう、より保守的に2%未満を目標に据える設計が安全です。

実務で最も多い失敗が、テスト時の架空アドレスへの大量送信です。実在しないアドレスへ送ればすべてバウンスとなり、率が一気に跳ね上がります。本番アカウントでのテスト送信は、停止の典型的な引き金です。

苦情率の超過

苦情とは、受信者がメールを「迷惑メール」として報告する行為です。Gmailの「迷惑メールを報告」ボタンなどがこれにあたります。

苦情率の基準はバウンス率よりさらに厳しく設定されています。苦情率が0.1%以上になると、アカウントはレビュー対象になります。苦情率が0.5%以上の場合は、高い苦情率の原因となった問題が解決するまで、以後のEメール送信を一時停止することがあります。

0.1%は「1,000通に1通」という非常に低い水準です。許諾を得ていない宛先への配信や、本文と件名の乖離、配信頻度の高さなどが苦情を招きます。

ここまでの基準を整理すると、次のようになります。

指標	レビュー対象	一時停止の可能性	推奨維持水準
バウンス率	5%以上	10%以上	5%未満（2%未満が望ましい）
苦情率	0.1%以上	0.5%以上	0.1%未満

スパムトラップへのヒット

スパムトラップとは、迷惑メール送信者を検出するために設置された「おとりのメールアドレス」です。本来は誰も使っていないアドレスのため、ここに送信が届くということは、リストの取得・管理方法に問題があるサインと見なされます。

SESの送信者がスパムトラップにヒットすると、スパムトラップを運営する特定の組織がSESに通知を送信します。アカウントがスパムトラップにEメールを送信していると判断された場合、アカウントはレビュー対象になり、根本的な問題を解決するよう求められます。

注意したいのは、スパムトラップの問題は段階を飛ばすことがある点です。スパムトラップの問題が非常に深刻である場合は、アカウントをまずレビュー対象にするのではなく、ただちにEメール送信機能を一時停止する可能性があります。古いリストや、購入したリストへの配信は特に危険です。

AWSサービス条件・送信ポリシー違反

バウンスや苦情の数値以前に、送信内容そのものがAWSの利用ポリシーに反していれば停止対象になります。アカウントから送信されたEメールがAWSのサービス条件に違反している場合や、アカウントが同じ問題について複数回レビュー対象とされた場合も、一時停止につながります。

特に見落としやすいのが「再発」です。アカウントが過去に何度も同じ問題でレビュー対象になっている場合、レビュー対象の原因となった個別の問題を解決するだけではなく、根本的な問題に対処することが重要です。特定のキャンペーンが原因なら、そのキャンペーンを単に停止する以上に、どのような特徴が問題だったかを特定し、今後同じ問題が発生しないようにするプロセスを構築する必要があります。

アカウント停止が事業に与える影響

数値基準を理解したところで、実際に停止されると何が起こるのかを確認します。影響範囲を把握しておくことで、停止時の初動を誤らずに済みます。

メール送信が全面的に止まる

送信一時停止になると、Amazon SES経由のメールはすべて止まります。マーケティングメールだけでなく、会員登録完了、パスワードリセット、注文確認、配送通知といった、ユーザー体験に直結するトランザクションメールも届かなくなります。

実際に停止を経験した事例では、新規会員登録や問い合わせフォームといったメール送信を伴う機能や導線を一時的に停止・非表示にし、決済の受付まで止めざるを得なかったという報告があります。メールが止まることは、単なる「連絡の遅延」ではなく、サービスの根幹機能の停止に直結するのです。このリスクの大きさこそ、停止を「起きてから対応する」のではなく「起こさない設計」で臨むべき理由です。

他のAWSサービスへの影響範囲

幸い、Amazon SESの停止が即座にシステム全体を止めるわけではありません。Amazon SESの送信が一時停止されても、AWSアカウントの他のAWSサービスには影響しません。ただし、アウトバウンド通信を送信するAWSサービスにおけるサービスクォータの増加は、送信の一時停止が解除されるまで拒否される場合があります。

EC2やS3、RDSなどが止まるわけではないため、システム全体がダウンするわけではありません。とはいえ「メールが送れない」状態が長引けば、サービスとしての信頼は確実に損なわれます。被害を最小化するには、復旧手順をあらかじめ把握しておくことが欠かせません。

Amazon SESのアカウント停止を解除する手順

停止されてしまった場合、サポートへ単に解除を依頼するだけでは再開は承認されません。Amazon SESが求めているのは「原因の特定」と「再発防止の証明」です。次の4ステップで進めます。

STEP1 SESチームからの通知メールを読み、原因を特定する

まず、AWSアカウントに登録されたメールアドレス宛に届く、Amazon SESチームからの通知を必ず確認します。この通知には、送信アカウントのレビューまたは一時停止の原因となった問題（バウンス、苦情、スパムトラップなど）の概要がまとめられています。

ここで原因の方向性を正しくつかむことが、その後の対策の精度を決めます。バウンスが原因なのか、苦情が原因なのかで、打つべき手はまったく異なるためです。

STEP2 根本原因に対する具体的な対策を実施する

原因を特定したら、それを解消する具体的な対策を実施します。Amazon SESが評価するのは「再発しない仕組みを作ったか」であり、表面的な対症療法では解除されません。

バウンスが原因の場合は、バウンスしたアドレスを送信リストから速やかに削除し、無効アドレスへ再送しない仕組みを整えます。苦情が原因の場合は、許諾の取得状況を見直し、配信停止導線を明確にします。

実際の解除事例では、テスト環境ではメールボックスシミュレーターを使用することを徹底し、CloudWatchアラームでバウンス率5%・苦情率0.1%を超えた際に通知が届くよう設定した、といった再発防止策を講じたうえでサポートへ回答しています。

STEP3 サポートケースから新規レビューをリクエストする

対策を実施したら、AWSマネジメントコンソールの「サポート」から該当のサポートケースを開き、返信する形で新規レビュー（再審査）をリクエストします。

伝えるべき内容は決まっています。「原因は何だったか」「どのような対策を実施したか」「今後どう再発を防ぐか」の3点を、具体的に記載することが重要です。返信文の骨子としては、以下のようなテンプレートが使えます。

【発生した問題】
バウンス率が基準値を超過したため、送信が一時停止となりました。

【根本原因】
テスト送信時に、実在しないアドレスへ多数のメールを送信していたことが原因です。

【実施した対策】
・バウンスしたアドレスを送信リストから全件削除しました。
・テスト環境ではメールボックスシミュレーターのみを使用するルールを徹底しました。
・送信前にアドレスの形式・有効性を検証するプロセスを追加しました。

【再発防止策】
１，CloudWatchアラームを設定し、バウンス率5%・苦情率0.1%を超えた時点で
２，担当者へ通知が届くようにしました。これにより基準超過前に検知・対応できます。

STEP4 補足質問への回答と解除後の確認

リクエスト後、Amazon SESチームが内容を審査します。Amazon SESチームは、新規レビューのリクエストを受け取った後に、送信アカウントのレビューまたは一時停止を継続するか終了するか決定します。新規レビューが正常に行われなかった場合、補足の質問への回答を求められるため、必ず回答してください。

対策内容が十分と判断されれば、レビュー期間がキャンセルされるか、一時停止が解除されます。解除までの時間はケースにより異なりますが、十分な対策を提示できれば、数時間〜数日で解除されたという報告もあります。回答後は放置せず、サポートケースの返信を継続的に確認しましょう。

アカウント停止を繰り返さないための予防策

一度解除されても、同じ問題を繰り返せば停止のハードルはさらに下がります。停止を「起こさない」ための恒常的な仕組みづくりこそ、最も費用対効果の高い対策です。

バウンス・苦情を発生させないリスト管理

すべての土台は送信リストの品質です。バウンスが返ってきたアドレスは即座にリストから除外し、再送しないことが鉄則。バウンス率の悪化を防ぐには、エラーとなったメールアドレスを特定し、直ちに送信リストから除外する運用が不可欠です。

長期間反応のないアドレスや、取得経路が不明なアドレスも、苦情やスパムトラップの温床になります。定期的なリストのクリーニングを運用フローに組み込みましょう。

CloudWatchアラームで閾値を監視する

停止の最大の問題は「気づいたときには手遅れ」になりやすい点です。これを防ぐのがCloudWatchアラームによる監視です。

Amazon SESではバウンス率を5%未満、苦情率を0.1%未満に維持することが推奨されており、アラームのしきい値はバウンス率0.05（5%）、苦情率0.001（0.1%）に設定することがおすすめされています。レビュー対象になる水準でアラートが鳴るよう設定しておけば、一時停止に至る前に対応できます。

テスト時はメールボックスシミュレーターを使う

本番アカウントでのテスト送信は、バウンス率急騰の典型的な原因です。これを避けるため、テストにはAmazon SESが提供するメールボックスシミュレーターを使います。

メールボックスシミュレーターを使用すると、送信クォータやバウンス・苦情の指標に影響を与えずにEメール送信プロセスをテストできます。シミュレーターでは、バウンス、苦情、配信成功など、さまざまなシナリオをテストできます。テスト用の架空アドレスを使う運用は、今すぐ見直すべきです。

認証（SPF/DKIM/DMARC）と配信品質の維持

送信ドメイン認証であるSPF・DKIM・DMARCの設定は、なりすまし対策であると同時に、受信側からの信頼を獲得し迷惑メール判定を回避するための基盤です。認証が不十分だと苦情率の上昇を招き、結果的に停止リスクを高めます。これらの設定を正しく維持することが、長期的な配信品質の前提となります。

停止リスクの根本対策として、別のメール配信サービスを利用する

ここまでの対策を講じても、アカウント停止のリスクは残ります。バウンスや苦情の管理、IPレピュテーションの維持、認証設定の運用をすべて自前で担い続けるのは、開発・運用チームにとって決して軽い負担ではありません。

メール配信システム（専用サービス）を使うメリット

メール配信に特化したサービスは、停止リスクの原因そのものを設計段階で吸収してくれます。Amazon SESの停止に悩むシステム担当者にとって、次のような価値があります。

• バウンス・苦情・IPレピュテーションの管理を提供側が運用し、停止リスクを大幅に低減できる
• API・SMTPリレーで既存システムに組み込め、移行コストを抑えられる
• SPF/DKIM/DMARCなどの認証基盤が標準で整備されている

メールサーバーの評価維持という「終わりのない運用業務」から解放され、本来のプロダクト開発にリソースを集中できる点が、専用サービス最大のメリットです。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、一斉配信やトランザクションメールを簡単に実現できる、開発者向けのメール配信サービスです。運用・メンテナンスをblastengine側が担うため、面倒なメールサーバー管理やIPレピュテーション維持の業務から解放されます。

• IPレピュテーション管理: blastengine側で運用・管理するため、共有IP起因の評価変動に振り回されず、常に高い送信者評価を維持
• バウンスメール自動対応: エラーメール管理を自動化し、バウンス率の悪化を未然に防止
• 99%以上の高いメール到達率: 国内キャリア・ISPへの個別送信ロジックで確実に届ける
• SPF/DKIM/DMARC対応: 最新のメール認証技術に標準対応し、なりすまし・迷惑メール判定を回避
• API連携・SMTPリレー: 既存システムへの組み込みが容易で、最短当日から利用開始可能

「停止に怯えながら指標を監視し続ける」運用から、「送ることに集中できる」運用へ。初期費用無料・月額3,000円〜で導入でき、メールアドレスの入力のみで無料トライアルが可能です。Amazon SESの停止リスクに課題を感じているなら、まずは気軽に試す価値があります。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ：Amazon SESのアカウント停止は「原因特定→対策→再発防止」が鉄則

Amazon SESのアカウント停止は、突然の災難ではなく、バウンス率・苦情率という明確な基準を超えた結果として段階的に起こります。レビュー（審査中）と送信一時停止の違いを理解し、自社の状態をダッシュボードで把握することが、すべての出発点です。

停止された場合の解除は、SESチームの通知で原因を特定し、根本対策を実施し、サポートケースで再審査をリクエストし、補足質問に回答するという流れで進みます。重要なのは、表面的な対処ではなく「再発しない仕組み」を提示することです。

そして最も効果的なのは、停止を起こさないこと。リスト管理の徹底、CloudWatchアラームによる監視、テスト時のシミュレーター利用、認証設定の維持を運用に組み込みましょう。それでも共有IP起因のリスクや運用負荷が課題なら、IPレピュテーション管理やバウンス自動対応を提供側が担う専用サービスへの移行が、最も根本的な解決策となります。

まずは自社のレピュテーションダッシュボードで現在のステータスを確認し、CloudWatchアラームの設定状況を点検することから始めてください。