Supabase Auth + AWS SES環境で、無効なサインアップによるバウンスを送信前に減らす構成 (Next.js)

Posted at 2026-10-15

概要

Supabase AuthとAWS SES（またはResend）を組み合わせて本番運用している場合、見落としがちな重大なリスクがあります。それが AWS SESのバウンス率（Bounce Rate）の基準 です。

AWSの公式ドキュメントでは、バウンス率が5%を超えるとアカウントが審査（Under review）の対象となり、さらに高い水準（10%）に達すると送信機能が一時停止される場合があると明記されています。（※最新の基準は必ずAWS公式ドキュメントをご確認ください）

本記事では、使い捨てメールアドレスや存在しないドメインによってバウンス率が跳ね上がるメカニズムと、メール送信パイプラインの前段でアドレスを検証しバウンスを未然に防ぐ「Pre-flight（送信前）」アーキテクチャを紹介します。

Webサービスを一般公開すると、/signup やパスワード再設定のエンドポイントに、使い捨てメール（Temp-mail）や存在しないドメインのアドレスが大量に入力されるケースがあります。短時間に多数の無効アドレスが注入されると、次のような連鎖障害が発生します。

多くの解説記事では、AWS SNSやSQSでバウンス通知を受信し、Suppression List（配信停止リスト）に追加する方法が推奨されています。

もちろんこれは必須の設計ですが、あくまで「すでにメールを送信し、バウンスが記録された後」の事後処理に過ぎません。突発的なBot攻撃で一気にバウンスが発生してしまった場合、AWS側の評判スコアへのダメージはすでに確定してしまいます。

そこで事後処理に加えて、SESやResendにリクエストが届く前に、使い捨てドメインや存在しないドメインを判定して手前で破棄する「Pre-flight（送信前）」の構成が極めて有効な防護策となります。

[ Supabase Auth イベント ]
│
▼
[ SentriSend 送信前検証API ] ──(使い捨て・存在しないドメインを遮断: HTTP 400)
│
▼
[ AWS SES / Resend ] ──(検証を通過した正規アドレスのみ送信)

SentriSend ( https://sentrisend.com ) は、メール送信パイプラインの直前に1回の軽量なAPI呼び出しでアドレスの健全性を検証する開発者向けAPIです。以下の項目を高速に判定します。

使い捨てドメインと判定された場合は、以下のようにHTTP 400と共に理由が返されます。

{
"allowed": false,
"disposable": true,
"reason": "DISPOSABLE_DOMAIN",
"risk_score": "HIGH"
}

問題がなければHTTP 200で "allowed": true が返ります。なお、DNSの応答遅延などで結果が確定できない場合は、正規ユーザーの利便性を損なわないよう「フェイルオープン（許可 / リスクスコア MEDIUM）」として扱う安全設計になっています。

導入にあたっては、以下のスコープ外の事項についてもご留意ください。

個別のメールボックス実在確認は行いません: 実在するドメイン（Gmailなど）のアドレスであっても、アカウント名が存在しない場合はバウンスする可能性があります。（※Gmail等への過度なSMTP接続による自社IPのブラックリスト入りを防ぐための業界標準仕様です）
Bot自体のアクセス遮断ツールではありません: 本APIが検証するのは「アドレスの健全性」です。不正アクセスそのものを防ぐには、Cloudflare Turnstileやレート制限との併用を推奨します。
事後バウンス処理の完全な代替ではありません: 万全を期すため、従来のSNS / SQSによるバウンス通知処理との併用を前提としています。

クレジットカードの登録不要で、月100リクエストまで無料で利用できる開発者サンドボックスを提供しています。
公式ドキュメント、APIリファレンス、実装サンプルは以下よりご確認いただけます。
- 公式サイト: https://sentrisend.com
- GitHub: https://github.com/sentrisend/SentriSend

サインアップエンドポイントのスパム対策やSESのバウンス率維持について、皆様の開発現場でどのようなアプローチを取られているか、ぜひコメント欄で知見を共有いただけますと幸いです！