顧客、ブランド、環境ごとに専用のキー、ドメイン、レポートを用意でき、自前のメールサーバーを運用する必要はありません。
エージェント対応APIとAIサポートトリアージを備えた、SaaS向けマルチテナントメール
1社のテナントがスパムを送り、全体に影響する
ワークスペース別の上限と抑止リストで、1つの送信者が他に害を及ぼすのを防ぎます。
顧客が自分の送信ドメインを使いたがる
ドメインのオンボーディングと検証のフローは、APIを通じて動作します。
リリースのたびにメールが変わる
バージョン管理されたテンプレートで、プロダクトとサポートが安全に内容を更新できます。
マルチテナントメールは、各顧客を専用のキー、ドメイン、上限を持つ独立した単位として扱い、そのすべてをプロダクトから管理することで成り立ちます。
SaaS向けメールとは、ソフトウェア製品が自社のユーザーの代理で送るメッセージ全般を指します。ワークスペースへの招待、利用状況のアラート、ダイジェスト、請求通知、そして多くの製品では顧客自身のブランドで送るメールも含まれます。多数のテナントが1つの送信基盤を共有するため、通常のアプリのメールより難しく、開発者にとっての導入のしやすさを保ちながら、上限、ドメイン、キー、評判を分離する設計が求められます。優れた設計は、テナント同士が影響し合わないようにします。
初期のSaaSチームは、すべてを1つのアカウントと1つのドメインから送信します。顧客が増えるにつれ、問題が積み重なります。1つのテナントの不良リストが全体の到達率を下げる、顧客が自社ドメインでの送信を求める、プロダクトとサポートがリリースなしでテンプレートを編集したい、特定のユーザーに招待が届かなかった理由を誰も説明できない、といったことです。テナント管理機能を自社で構築すると、本来の製品開発に充てるエンジニアリングの時間が奪われます。その間、サポートは答えを持てません。
MigoMTA上に構築されたMigoSMTPは、キー・上限・レポートが独立したワークスペース、APIによるドメインのオンボーディング、バージョン管理されたテンプレート、配信状況をプロダクトに返すwebhookを提供します。エージェント対応APIとサポートコパイロットにより、チームは「なぜ届かなかったのか」により早く答えられ、バウンスのパターンが通常と異なるテナントにフラグを立てられます。停止や設定変更は人が承認します。レポートはワークスペース別に結果を分解して表示します。
チームメイトの操作で送る招待メールの配信イベントをアプリに返します。招待した人はバウンスしたかどうかを確認でき、アドレスを修正できます。
しきい値を超えたら管理者に通知します。優先送信によりアラートがダイジェストの後ろに並ぶことはなく、配信は監査証跡に記録されます。アラートは監査可能な状態に保たれます。
週次サマリーをワークスペースとユーザーごとに実行し、スロットルをかけます。大規模テナントのダイジェストが、同時刻に小規模テナントが必要とする容量を使い切ることはありません。
顧客がオンボーディングフローで自社ドメインを検証し、自社ブランドで送信できます。初回利用前にSPFとDKIMのチェックを完了させます。未検証のドメインはブロックされたままです。
テナントが検証済みの自社ドメインから送信できる一方、上限と抑止リストはお客様が管理します。
プランの上限に近づいたときに顧客へ警告し、支払いを確認します。すべてバージョン管理できるテンプレートから送信されます。
初期は1つのアカウントでシンプルに。テナントが増えたら、分離がすべてを守ります。
最初のテナントからワークスペースで始めましょう。後から移行するのは、最初から分離しておくよりずっと大変です。
ユーザーのメールアドレスを入力して、招待が届かなかった理由を尋ねます。コパイロットはメッセージログを読み、配信経路を要約します。スタッフの承認なしに、再送や編集はできません。
バウンスや苦情のパターンが通常から外れているワークスペースを見つけ、確認用に表示します。警告、制限、様子見のどれにするかは、チームが決めます。
MCP互換のインターフェースにより、承認済みの社内エージェントがスコープ付きキーでワークスペースの作成やドメインの状態確認を行えます。影響の大きい操作には、人による承認ステップを必須にできます。すべての呼び出しが記録されます。
プロダクトのメールを翻訳または書き換えたドラフトを、確認用に作成します。バージョン管理されたテンプレートで公開される前に、プロダクトオーナーが各バージョンを編集して承認します。
AI機能は補助と助言の役割です。エンジニアリングとサポートのチームが提案を確認し、テナント、テンプレート、送信に関する判断は引き続きチームが行います。
顧客ごとにキー、上限、レポートを分けることで、1つの問題ある送信者が他に影響せず、利用状況も明確に把握できます。
SPFとDKIMに合格するまで、顧客のドメインで送信しないでください。共有の評判を守るため、未検証のドメインはAPIでブロックします。
プロダクトのメールをバージョン管理されたテンプレートに保管すれば、サポートとプロダクトが文面を安全に更新でき、変更で問題が起きたらロールバックできます。
webhookを使って、操作の隣に配信済み・バウンス・保留を表示すれば、届かないメールに関するサポートへの問い合わせが減ります。
デフォルトの送信上限を設け、要望に応じて引き上げましょう。乗っ取られたアカウントが、誰かが気づく前に大量送信することを防げます。
テナントモデルを設計中ですか?弊社チームが一緒にレビューします。
テナントごとにワークスペースまたはサブアカウントを持つメールAPIを使い、それぞれ専用のキー、上限、レポートを設定します。送信ドメインを認証し、イベントをwebhookで戻し、テナント別の抑止リストを適用して、1社の不正なデータが他に影響しないようにします。
はい。ドメインのオンボーディングフローを使います。顧客がDNSレコードを追加し、お客様側でSPFとDKIMを検証してから、送信を有効にします。APIで自動化できるため、プロダクトが手作業のサポートなしに各顧客をセットアップへ案内できます。
ワークスペースを分けてテナントを分離し、送信上限を適用し、バウンスと苦情を自動で抑止し、テナントごとの率を監視します。高リスクまたは大量送信のテナントの挙動が他に影響し始めたら、そのテナントを専用のIPプールに移します。上限は、各テナントの成長に合わせて見直しましょう。
テンプレートをアプリケーションコードの外に、バージョン、変数、確認ステップ付きで保管します。これにより、プロダクトとサポートはデプロイなしで内容を編集でき、エンジニアは渡すデータを管理し、問題のある変更をロールバックできます。変更を追跡できるよう、リリースごとにタグを付けましょう。
webhookイベントを購読し、配信済み・バウンス・保留のステータスをデータベース内の関連レコードに保存します。これで、メールボックスを読まなくても、ステータスバッジや再送の案内をUIに表示できます。繰り返しの問い合わせも大幅に減ります。
ほとんどのSaaSチームは、メタデータ、冪等性、より詳細なエラーに対応するため、アプリケーションからの送信にHTTP APIを使います。SMTPは、レガシーシステム、プラグイン、サードパーティツールに便利です。両方を同じワークスペースで使えます。多くのチームが、競合なく両方を同時に運用しています。
できます。スコープ付きキーを使ったMCP互換インターフェースを通じて可能です。読み取り専用のステータス確認と送信ドラフト作成など、エージェントに許可する操作はお客様が決められ、機密性の高い操作には人による承認を必須にできます。
コパイロットは、ユーザーのメッセージログを読み、バウンスの理由や保留といった配信経路を平易な言葉で説明できます。要約はスタッフが確認し、その後の対応を判断します。