Supabase のアプリに必要なメールは、認証、製品イベント、ライフサイクルキャンペーンの3種類。Resend、Loops、Sequenzy、Brew を、それぞれが担える役割で比較します。

この比較は Brew が公開しているものです。2026年9月28日に、リンク先の各社の製品ドキュメントを確認しました。これはドキュメントに基づく比較であり、すべてのプラットフォームを実際に試したと主張するものではありません。最新のプランの上限は、各ベンダーの料金ページで確認してください。
Supabase のアプリをリリースし、チームの外から最初のユーザーが登録してくれました。ところが、確認メールはまだデフォルトの送信機能から送られています。この機能は事前に許可したアドレスにしか配信しないため、新しいユーザーには誰ひとり確認メールが届きません。予定していたウェルカムメールも、タスクリストのメモのままです。
Supabase のアプリがメールを送る理由は、3つあります。認証メールには、登録の確認、マジックリンク、パスワードリセットがあります。製品イベントのメールは、データベースで何かが起きたときに送信されます。ライフサイクルキャンペーンは、オンボーディング、利用を促すリマインド、休眠掘り起こしを担います。1つのツールで複数をまかなうこともできますが、Supabase は、認証メールとマーケティングメールを分けるよう勧めています。
このガイドでは、Resend、Loops、Sequenzy、Brew を、それぞれのドキュメントに記載されている役割ごとに整理します。
auth.users の変更を受け取り、auth.user.email_confirmed などのイベントを発生させます。Sequenzy は、選択したテーブルの行を同期します。| 役割 | 必要なもの | ドキュメントに記載があるツール |
|---|---|---|
| 認証メール | Supabase Auth が呼び出すSMTPサーバーまたは認証フック | Resend、Loops、Sequenzy |
| 製品イベント | データベースの変更をトリガーに変える仕組み | Brew(auth.users)、Sequenzy(任意の1テーブル)、Loops(コンタクトの同期) |
| ライフサイクルキャンペーン | シーケンス、デザインされたメール、オーディエンス | Brew、Loops、Sequenzy |
各ベンダーのドキュメントは、2026年9月28日に確認しました。
Supabase のSMTPガイドには、組み込みの送信機能の制限が挙げられています。送信先は、事前に許可したアドレスだけです。レート制限は1時間あたり2通と低く、予告なく変更されることがあります。配信についてのSLAもありません。Supabase は、テストやデモ以外の用途では、カスタムSMTPを設定するよう求めています。
同じページでは、認証メールとマーケティングメールを混在させないよう注意を促しています。サービスを分けるか、少なくとも auth.example.com と marketing.example.com のように送信ドメインを分け、認証メッセージには販促の内容を入れないようにしましょう。
Resend の Supabase 向けガイドは、短いSMTPの設定手順です。Supabase の「Authentication」で、ホストに smtp.resend.com、ポートに 465、ユーザー名に resend、パスワードにAPIキーを入力します。Resend で認証済みのドメインが必要です。設定が済めば、Supabase Auth は Resend 経由でメールを送信するようになります。
Loops は、Supabase と連携する2つの方法をドキュメントで紹介しています。認証フック(Auth Hook)を使うと、Supabase Auth のすべてのメールが Loops 経由で送られます。代わりにSMTPを使うこともできます。これとは別のコンタクト同期によって、Supabase のユーザーを Loops のオーディエンスに取り込めます。
Sequenzy は、自社のSMTPサービス経由で Supabase Auth のメールを送信できます。パスワードリセット、マジックリンク、招待、セキュリティ通知のトランザクションメール用テンプレートをデフォルトで用意してくれるほか、SMTPの認証情報を手動で入力することもできます。
Brew の Supabase 連携は Supabase Auth のメールを送信せず、Brew のドキュメントにはSMTPリレーの記載もありません。確認、マジックリンク、パスワードリセットのメールは、SMTPプロバイダーに任せましょう。Brew のAPIでは、領収書のように、アプリをきっかけに送るトランザクションメールを送信できます。ただし、Supabase Auth 自体のメッセージには、引き続きSMTPか認証フックが必要です。
Brew の Supabase 連携では、セットアップ用のスクリプトが auth.users にデータベーストリガーを追加します。このトリガーは、各変更に pgcrypto で署名し、pg_net で Brew 専用の Webhook に送信します。共有シークレットは Supabase Vault に保存されます。Brew がそのまま受け取るイベントは、auth.user.created、auth.user.updated、auth.user.deleted の3つです。さらに、列の変更から次の9つのイベントを派生させます:
auth.user.email_confirmed と auth.user.phone_confirmedauth.user.email_changed と auth.user.password_changedauth.user.signed_inauth.user.banned と auth.user.unbannedauth.user.invitedauth.user.upgraded_from_anonymousユーザーは、アカウントのステータス、メールアドレスの確認日時、最終ログインなどの supabase_* フィールドを持つコンタクトとして同期されます。Brew のドキュメントにあるとおり、トークンのリフレッシュでも last_sign_in_at が更新されるため、auth.user.signed_in だけでは「ユーザーが戻ってきた」ことを示す確かなシグナルにはなりません。
project_created や invite_sent のように auth.users の外で起きるイベントには、Brew でカスタムトリガーを作成し、Supabase Edge Function から発火させます。このパターンは、Brew の Lovable ガイドで紹介しています。Edge Function は Supabase のシークレットから BREW_API_KEY を読み取り、POST /v1/automations/triggers/{triggerEventId}/fire を呼び出します。
Sequenzy は、OAuthで Supabase に接続し、選択した1つのテーブル(一般的には public.profiles)を pg_net のトリガーで監視します。メールアドレス、ユーザーID、名前の列を自動で検出し、その他の列もセグメント化のために同期します。挿入では contact.subscribed が発生します。更新ではイベントを発生させずに属性を更新し、削除では contact.unsubscribed が発生します。自動の Webhook を使えるのは、1つの連携につき1つのテーブルだけです。
Loops は、Supabase のユーザーをオーディエンスに同期し、そのデータをもとにワークフローを開始できます。コンタクトの同期は、認証メールの経路とは別に設定します。
Brew は、ブランドの email-design.md をもとにメールを生成し、プロンプトからオートメーションを作成して、認証済みのドメインから送信します。ウェルカムフローを auth.user.email_confirmed で開始すれば、最初のメールは、確認を済ませた人にだけ届きます。Brew にはSMSのチャネルがなく、Supabase Auth のメールも扱いません。
Loops と Sequenzy は、認証メールに加えてライフサイクルキャンペーンにも対応しているため、1社で両方をまかなえます。その場合でも、Supabase の推奨どおり、認証メールとマーケティングメールで送信ドメインを分けましょう。
役割分担の一例を紹介します。最初から最後まで通してのテストはしていません。
auth.example.com のカスタムSMTP(Resend、Loops、Sequenzy のいずれか)経由で送信します。auth.users の変更を受け取ります。ウェルカムのオートメーションは、auth.user.email_confirmed で開始します。project_reminder_eligible を送信します。そのイベントをもとに、公開したオートメーションが利用を促すメールを送ります。あるいは、真偽値の has_project コンタクトフィールドを Brew に定義して同期し、待機のあとで contact.has_project equals false を確認する方法もあります。この条件が読み取るのは Brew のコンタクトフィールドの現在の値で、元のイベントのペイロードは変わりません。Supabase は、使えないとしています。デフォルトのサービスは、事前に許可したアドレスにしか送信できず、送信レートも低く、SLAもありません。カスタムSMTPを設定してください。
いいえ。Brew の Supabase 連携は、auth.users の変更をもとにオートメーションを開始するものです。確認メールやパスワードリセットのメールには、SMTPプロバイダーか認証フックが必要です。
email_confirmed を待つのはなぜですか?そうすれば、ウェルカムメールは有効なアドレスにだけ届きます。また、確認メールと同時に届くのではなく、確認メールのあとに届きます。
自動的にはみなされません。Brew のドキュメントでは、マーケティングメールの受信者は全員、インポート前にオプトインしている必要があるとしています。登録時に同意を保存し、それをもとに絞り込みましょう。
自分のプロジェクトからどのイベントが届くのかを確かめるには、Brew で Supabase を接続してテストユーザーを追加し、フローを公開する前に「最近のイベント」パネルを確認しましょう。
