Supabase公式のローカル開発では、Authメールは外部へ送信されず、ローカルのメール確認画面に捕捉されます（ローカルメールテストの説明）。今週は、まず環境を特定し、開発では捕捉画面、QAでは試験目的、リリース前は実際の受信結果を確認してください。ローカルでメールが見えても、実ユーザーの受信箱への到達確認にはなりません。
開発者には、登録確認やメールログインを実装中で、メール生成とリンク動作を切り分けたい方が向いています。
QA担当者には、環境ごとの失敗を再現可能な証拠と一緒に記録したい方が役立ちます。
リリースを控えた独立開発者や小規模チームには、送信設定と実受信の確認範囲を整理する材料になります。
開発担当：ローカル捕捉と外部送信を混同しない
ローカル開発では、Authが生成したメールは外部の受信箱へ直接届くのではなく、ローカルのメール確認画面に取り込まれます。標準構成の画面は http://localhost:54324 です（Supabase CLIのローカル設定）。
ここでメールが見つからない場合は、実際に操作したプロジェクトとローカル環境が一致しているかを確かめます。そのうえで、登録や再送信などの操作、宛先ユーザー、メール種別を順に確認してください。生成されたメールがあれば、テンプレートの内容と確認リンクを調べます。
ローカル画面にメールがあることは、生成・捕捉されたことの確認です。外部SMTPへの引き渡しや、受信箱への到着を示すものではありません。
テンプレートでは、利用している変数と確認リンクの形式を現行設定に照らします。リンクが意図したアプリへ戻るかどうかは、メール本文だけでは判定できません。ローカル用のテンプレート設定はSupabaseのローカルメールテンプレート文書を、托管プロジェクトのテンプレートはAuthメールテンプレートの説明を参照してください。
QA担当：内容確認と実受信を分けて試験する
「メールが届くこと」をひとつの試験結果にまとめると、テンプレートの不具合と送信制限を見分けにくくなります。まず、テストの目的を次のように分けます。
| 試験したいこと | 主な確認場所 | 合格の根拠 |
|---|---|---|
| メール本文・テンプレート | ローカル捕捉画面または対象環境のメール | 宛先、件名、本文、変数が想定どおり |
| 確認リンク・認証フロー | メール内リンクとアプリ | 認証後に期待する画面・状態へ進む |
| 外部受信箱への到着 | 外部送信を許可したテスト環境 | 指定した受信先でメールを確認できる |
QAの記録には、環境名、Authプロジェクト、操作内容、テスト用の受信アドレス、発生時刻、画面やログの証拠を残します。再試験では変更した設定も記録すると、単に同じ操作を繰り返すより原因を絞れます。個人のメールアドレスを試験データに流用せず、テスト用アドレスを使う運用はメールアドレスとプライバシーの考え方とも整合します。
役割ごとの確認項目
| 担当 | 先に確かめること | 問題が残る場合 |
|---|---|---|
| 開発 | ローカルか托管環境か、操作が実行されたか | 捕捉画面、Authイベント、テンプレート |
| QA | 内容・リンク・外部到着のどれを試すか | 環境、宛先、操作時刻、再現記録 |
| プロジェクト管理 | SMTP設定と送信先の許可条件 | Authログのエラー、現在の送信制限 |
| リリース担当 | 実ユーザー経路を対象にするか | 承認済みの受信先で実送信を確認 |
プロジェクト管理者：標準送信サービスとSMTP設定を照合する
托管プロジェクトでは、ローカル捕捉とは異なり、Authの送信処理がメールサービスへ進みます。ただし、標準の送信サービスにはテスト用途の制限があり、宛先が許可範囲外なら実受信試験に使えない場合があります。SupabaseのAuth SMTP文書で、現在の送信先条件と上限を確認してください。既定の制限を超えるテストが必要なら、自社の製品に適したSMTP設定を用意します。
具体的には、プロジェクトのSMTP設定が有効か、設定先が意図した環境か、宛先がその送信条件を満たすかを確認します。Authログに拒否や送信失敗が出ていれば、まずプロジェクト側の処理を調べます。Auth側で送信が失敗した場合と、メールサービスが受け取った後に受信箱へ届かない場合は、調査する担当も証拠も異なります。AuthのエラーコードとAuthメールが届かない場合の公式トラブルシューティングを使い、ログの内容に沿って切り分けます。
送信サービスがメールを受け取った記録だけでは、受信箱への到着や迷惑メール判定までは確認できません。受信側の結果も別に残してください。
リリース担当：確認リンクと実際の到着を別々に判定する
確認メールの生成後は、リンクの遷移先も試験します。メールに含まれる確認用URLと、アプリが処理する認証後の状態を確認してください。期待した画面に戻らない場合は、プロジェクトで許可されたリダイレクト先と、アプリ側のリンク処理を別々に調べます。リダイレクトURLの設定文書を参照し、設定上許可されたURLと実際の遷移先を照合してください。
リリース前に外部の受信箱、送信元、ユーザーの操作経路まで確認する必要があるなら、ローカル捕捉だけでは合格にできません。自社製品のステージング環境で、許可されたテスト用受信先へ実際に送信し、Authログと受信結果をひと組で保存します。単独のテスト結果から、他の宛先や受信サービスでも同様に届くとは判断しないでください。
開発・QAのメールテストで個人情報を含めない方針は、テスト用アドレスの選び方を決める際にも役立ちます。登録確認の試験で一時的な受信先を使う場合は、対象環境の送信制限に合うか、リンクを最後まで確認できるかを先に確かめます。
FAQ：症状から次の確認先を決める
ローカル開発の確認メールはどこに表示されますか？
ローカルのメール確認画面を開き、操作したユーザーの宛先と送信内容を見ます。標準画面は http://localhost:54324 です。メールが表示されても、外部受信箱への配信を確認したことにはなりません。
テストメールが実際の受信箱に届かないのはなぜですか？
ローカル開発ではメールが捕捉され、通常は外部へ送信されません。托管環境では、標準メールサービスの送信先制限やSMTP設定も確認します。Authログで拒否・失敗を調べ、送信サービスへ引き渡された後の不達とは分けてください。
宛先が許可されていない場合はどうしますか？
まず使用中の環境とプロジェクトを特定し、Auth SMTPの現行条件に宛先が合うか確認します。必要なら許可されたテスト用受信先を使うか、自社のSMTPを設定します。制限を回避する目的で、他社サービスへの大量登録を行う手順ではありません。
メールが送信サービスへ渡ったことはどう確認しますか？
Authログで該当する操作とエラーの有無を確認し、送信側の記録と受信側の結果を照合します。Authログに失敗がないことだけでは、外部の受信箱に届いた証明になりません。環境、宛先、操作時刻をそろえて証拠を残します。
症状別チェックリスト：同じ操作の繰り返しを避ける
- [ ] 使用環境がローカル、ステージング、本番のどれかを記録する
- [ ] 登録、再送信、メールログインなど、実行した操作を記録する
- [ ] ローカルならメール確認画面、托管環境ならAuthログを先に調べる
- [ ] 宛先が現在の送信サービスの許可条件に合うか確認する
- [ ] エラーがある場合、Auth側の失敗か送信サービス接手後の問題かを分ける
- [ ] リンクの表示内容、許可されたリダイレクト先、アプリ側の処理を個別に試す
- [ ] 実受信が合格条件なら、ステージングからテスト用アドレスへ送って結果を保存する
ローカルで見えない場合は捕捉画面と環境の一致、送信拒否ならSMTP条件とAuthログ、送信側で受け付け済みなのに見当たらない場合は受信側の記録が最初の確認先です。確認リンクが誤った場所へ進む場合は、配信の再試行ではなくリダイレクト設定とアプリ処理を調べます。
QAが自社製品の実受信を試す際、テスト用アドレスは選択肢のひとつです。短期間の登録確認やメールフローの検証なら、主メールアドレスを公開せずに使えるSendTmpの一時受信先を試験用に使う方法もあります。銀行、決済、行政など長期の本人確認やアカウント復旧に使う宛先には適しません。用途を限定し、送信設定とリンク動作の確認を別々に記録してください。
よくある質問
ローカル開発で送信した確認メールはどこで確認できますか？
ローカルのメール確認画面を開き、操作したユーザーの宛先と送信内容を確認します。標準のローカル設定では画面のアドレスは http://localhost:54324 です。ここに表示されたことはメールが生成・捕捉された証拠であり、外部の受信箱へ届いた証拠ではありません。
テストしたのに確認メールが普段の受信箱に届かないのはなぜですか？
ローカル開発ではメールが捕捉され、外部へ配信されないためです。托管プロジェクトでも、標準送信サービスの宛先制限や送信上限に該当する場合があります。Authログで送信処理の失敗を確認し、実際の受信試験は自社製品のテスト環境と適切なSMTP設定で行います。
宛先が許可されていないと表示されたら何を確認しますか？
まず、使用中のプロジェクトがローカルか托管環境かを確認します。托管プロジェクトの標準メールサービスには送信先の制限があるため、Auth SMTPの現行仕様とプロジェクトのSMTP設定を照合してください。制限に該当する場合は、承認されたテスト宛先を使うか、自社のテスト用SMTPを設定します。
Authログで送信サービスへの引き渡しを確認するには？
対象ユーザー、操作時刻、メール種別を手掛かりにAuthログの該当イベントを調べ、拒否や送信エラーの有無を確認します。エラーがなくても外部受信箱への到着までは証明できません。SMTP側のログや受信結果も合わせ、Auth側の失敗と送信後の不達を分けて記録します。