運用とリリース

トランザクションメール

Resend、React Email テンプレート、安全なローカル認証リンク、永続ジョブによる配信を設定します。

スターターのコミット 7580470 と同期済みです。

メール確認、パスワード復旧、請求、招待、予約確認を有効にする前に使います。Sushi SaaS が提供するのは Resend と React Email という具体的な構成で、複数のメール配信事業者を切り替える抽象化ではありません。そのまま採用するか、テンプレートと呼び出し契約を保ったまま src/services/email/send.ts を置き換えます。

ユーザーへ送るメールを決める

  • 送信ドメインを検証し、利用者が認識しやすい EMAIL_FROM を選びます。SPF、DKIM、DMARC の設定も機能の一部です。
  • メール確認とパスワード再設定はユーザーが待つため、認証リクエスト内で送ります。歓迎、請求、招待、予約のメールは、永続ジョブから少し遅れて届いても問題ありません。
  • ローカルでは認証リンクをログに出せますが、本番ではその設定を明示的に拒否します。

本番準備完了の条件: 実際の受信箱ですべてのテンプレートを受信でき、リンクが正しいドメインと言語のページへ戻り、ジョブを再試行しても外部サービスからの配信は一度だけで、拒否された配信がキューと稼働準備の監視に現れることです。

Resend と React Email は統合済みです。RESEND_API_KEY と検証済み EMAIL_FROM を設定し、本番では SPF、DKIM、DMARC を整えます。

メールアドレスの確認、パスワード再設定、歓迎、支払い成否、予約確認、組織への招待のテンプレートがあります。src/services/email/ で調整し、配信の調整処理はサービス層に置きます。

ローカルでは、配信事業者が未設定か AUTH_DEV_EMAIL_LINKS=true の場合に、認証リンクをログへ出力できます。本番ではこの設定を拒否します。プロダクトから送るメールは永続ジョブで処理し、ジョブ UUID を配信事業者向けの冪等性キーに使います。/api/cron/jobs を動かし、稼働準備状態の悪化と再試行回数の枯渇を監視します。

ルートから完了を待たずに送信する実装にはせず、公開されたテストメール用エンドポイントも作りません。機能データの書き込み後にキューへ登録し、個人情報を最小限に抑え、失敗、再試行、重複、ブロックリスト、多言語リンクをテストします。キューの実行と監視は永続ジョブと稼働準備へ進んでください。

トランザクションメール · Sushi SaaS