2026年、Supabase無料プロジェクトのメールテンプレート制限後、登録メールをどうテストする？

登録確認メールが届かず、テンプレート制限なのか送信設定なのか切り分けられない。
まずは現在のプロジェクトで使える既定テンプレートを使い、送信要求・実受信・アカウント認証を順に検証してください。ブランド文面まで検収する場合は、プロジェクトへの適用ルールを確認してから自社SMTPなどを検討します。テスト用メールアドレスが受信先として許可されるかは、実際の送信設定によって異なります。

新しく作成したSupabase無料プロジェクトで登録確認メールを試したい独立開発者向けです。
メールの送信要求と実受信、認証完了を区別したいQAエンジニアにも役立ちます。
認証メールを担当する技術責任者は、テンプレート制限と送信方式のどちらを見直すべきか判断できます。

最終更新日：2026年10月25日。Supabaseの公式変更告知、メールテンプレート文書、自社SMTP文書を照合しています。ルールはプロジェクトの作成時期と現在の構成で変わるため、実施時には公式資料とプロジェクト設定を再確認してください。

準備：まずプロジェクトの条件を確定する

Supabaseの告知では、2026年6月3日以降に作成した無料プロジェクトについて、既定のメール送信サービスを使用する場合、認証メールテンプレートを変更できないと案内されています。対象条件や例外は、Supabaseの無料プランにおけるテンプレート変更の告知で確認できます。

この条件を、すべてのSupabase環境に当てはめないことが重要です。告知では、以前に作成された無料プロジェクト、付与されたプラン、自社SMTPを使う構成、自前でホストするプロジェクトが区別されています。ローカル開発環境もホスト型プロジェクトとは別に扱い、同じテンプレート動作や送信結果になると決めつけないでください。

Supabase Authのテンプレート編集可否と、メールを送信できるかどうかは別の論点です。前者は文面やテンプレートの変更権限、後者は送信方式や許可条件に関係します。公式のAuthメールテンプレート文書と、現在のプロジェクト設定を並べて確認してください。

検収基準：機能の確認とブランド表現を分ける

自家製品の登録機能を確かめるだけなら、メール本文のデザインより、確認リンクまたはコードが動作し、最終的にアプリ側のアカウントが認証済みになることが中心です。既定テンプレートでこの流れを確認できるなら、機能テストのためだけにテンプレート設定を変更する必要はありません。

一方、ブランド名、独自の案内文、レイアウト、テンプレート変数の表示までリリース条件に含むなら、既定メールを受信しただけでは合格にできません。変更可否と送信方式を別々に調べ、テンプレート本文で使用する変数は公式テンプレート文書に記載された形式と照合します。たとえば {{ .ConfirmationURL }} や {{ .Token }} を使う場合、実際の設定と期待する認証手順が一致しているかを確認してください。

実行：登録要求とテストアカウントを記録する

テストは、自家製品の隔離された開発・検証プロジェクトで行います。第三者サービスのアカウントを大量に作る用途ではなく、自分が管理または検証を許可された環境に限定してください。

• テスト対象のプロジェクトと環境を記録します。開発用と本番用の設定を取り違えないよう、対象を明示します。
• テスト用アカウントに使う受信先を決め、プロジェクトの現在の送信方式で利用できるか確認します。
• 登録フォームから一度登録要求を出し、使用した受信先、実行環境、アプリの応答を記録します。
• 送信が拒否された場合は、ログや設定に基づき送信先の許可条件と制限を調べます。テンプレート制限だけを原因と判断しないでください。

この段階でアプリが成功応答を返しても、受信先でメールを確認するまでは送達の証明になりません。SupabaseのAuth送信制限に関する資料も確認し、失敗が設定、許可範囲、送信制限のどこに関係するかを切り分けます。正確な条件は、プロジェクトの現在の構成に照らして判断してください。

受信後：メールと確認情報を照合する

許可され、実際に内容を読めるテスト用メールアドレスで受信を確認します。宛先が今回の登録アドレスと一致するか、確認リンクまたはコードが今回の登録要求に対応しているかを見ます。テスト用受信先の選び方や受信確認の考え方は、メールの到着時間と確認方法も参考になります。

リンクを開いた後は、ブラウザーに表示されたページだけで完了とせず、アプリ側のアカウント状態を確認します。確認リンクやリダイレクトの設定値はテンプレート文書と照合し、ローカル環境の結果をホスト型プロジェクトの結果と同一視しないでください。

ローカルでメールテンプレートを調整する場合は、Supabaseのローカルテンプレート設定文書を参照してください。ただし、ローカル環境で本文を確認できても、それだけでホスト型プロジェクトからの送信や実際の受信状況まで検証したことにはなりません。

条件別FAQ：変更可否と受信先を切り分ける

新しい無料プロジェクトでは登録確認メールを変更できますか？

公式告知では、2026年6月3日以降に作成した無料プロジェクトが既定メールサービスを使う場合、認証メールテンプレートの変更はできないとされています。ただし、自社SMTPや別プラン、自前ホストの扱いを一律に推定せず、現在のプロジェクトに適用される条件を告知と設定画面で確認してください。

既定テンプレートで登録確認の一連の動作を試せますか？

機能の検証であれば、送信要求を出し、許可された受信先でメールを読み、確認リンクまたはコードを使って、アプリ側の認証状態まで追えば確認できます。ブランド文面や独自デザインが要件に含まれる場合は別の検収項目にしてください。既定メールの受信は、独自テンプレートの見た目を証明しません。

既定の送信サービスが任意のテストアドレスを受け付けないのはなぜですか？

プロジェクトが使うメール送信方式には、送信先の許可条件や送信制限が関係する場合があります。受信拒否や送信エラーが起きたら、テンプレートが編集できない問題と混同せず、現在の設定と公式の送信制限を照合します。許可範囲を確認する前に、すべてのテスト用アドレスが利用可能だと仮定しないでください。

メールを受信したら、ほかに何を確認すべきですか？

今回の登録先に届いたメールかを確かめ、確認リンクまたはコードが今回の要求に対応しているかを検証します。続けて確認操作を行い、アプリが期待する画面へ遷移するか、アカウントの認証状態が変わるかを確認してください。受信箱に表示されたことだけでは、確認処理の完了は分かりません。

選択：テンプレート要件に応じて次の手段を決める

次の条件分岐で、機能テストとブランド化の要件を整理できます。

• 登録フローの動作確認が目的で、既定テンプレートで確認リンクやコードを検証できるなら、まず現在の設定のままテストを続けます。
• メールの送信要求は通るのに受信できないなら、テンプレート変更を先に検討せず、送信方式、許可された受信先、送信制限を調べます。
• 独自の文面やブランド表現がリリース条件なら、プロジェクトの作成時期とプランを照合し、自社SMTPまたは適用可能なプランを評価します。
• ローカルでの表示確認だけができているなら、ホスト型プロジェクトでの実受信と認証完了は未検証として記録します。

自社SMTPへの切り替えはテンプレートを管理する選択肢になり得ますが、設定変更だけでメールの到達が保証されるわけではありません。送信サービスの認証や送信制限、アプリ側の確認処理を別々に検証し、変更後も同じテスト手順で実受信と認証状態を確認してください。

自家製品の登録フローで一時的に受信するだけなら、主メールアドレスをテストデータに使わず、使い捨てのテスト用受信先を選ぶ方法もあります。OrbSendは、登録不要ですぐ使える一時メールとして、主メールアドレスを公開せずに受信を試したい場合の選択肢です。利用前に、Supabase側でその受信先が許可されていることを確認してください。長期利用する重要アカウントや、後から返信・継続受信が必要なアカウントには適しません。用途に合う場合は、OrbSendの一時メールをテスト先の候補にできます。

よくある質問