時間に敏感なメールには、高速で予測可能な配信と、問題発生時の明確な可視性が必要です。
高速で追跡可能なトランザクションメール。AIコパイロットがあらゆる失敗を説明します
パスワードリセットが迷惑メールに入る、または遅れて届く
IPプールを分け、監視することで、トランザクションのトラフィックを一括送信メールから切り離します。
失敗を顧客から知らされる
webhookとメッセージログで、すべてのバウンスと保留がリアルタイムで分かります。
マーケティング送信が重要なメールに悪影響を与える
ストリームとプールでトラフィックの種類ごとに分離し、一方が他方を損なわないようにします。
トランザクションメールは、短く予測可能な経路をたどります。各経由点が可視化されているため、リセットメールが届かなくても、原因不明ではなく調べれば分かる問題になります。
トランザクションメールとは、ユーザーが何かを行ったことを受けて、アプリケーションが送る1対1のメールです。パスワードのリセット、請求書の支払い、新しいデバイスからのサインイン、注文などが該当します。キャンペーンとは異なり、受信者は数秒以内に届くことを期待しており、そのメールがないと先に進めないことも少なくありません。トランザクションメールサービスは、SMTPまたはHTTP APIでこれらのメッセージを受け取り、署名し、受信者のメールボックスプロバイダーへ配送して、1通ごとの結果を報告します。
多くのチームは、アプリケーションサーバーや共有のマーケティングアカウントから送信を始めます。それで問題ないのは、パスワードリセットが迷惑メールに入る、リトライで領収書が二重に送られる、プロモーションの一斉配信がその後ろのワンタイムコードを遅らせる、といったことが起きるまでです。送信者はアプリから出たメッセージをほとんど見られないため、問題の最初の兆候は、たいていサポートへの問い合わせです。認証の不備、共有IP、イベントデータの欠如は、こうした問題の追跡を難しくします。
Rackwave TechnologiesがMigoMTA上に構築したMigoSMTPは、トランザクションメールに専用のストリーム、オプションの専用IP、webhook、検索可能なメッセージログを提供します。AIコパイロットは、バウンスコードや保留を読み取り、考えられる原因と対処を平易な言葉で提案できます。異常検知アラートは、遅延の急増にフラグを立てられます。すべての提案はチームが確認し、何を変更するかを決めます。レポートは、宛先やIDで検索できます。
数秒以内に届く必要があるリセットリンクやワンタイムコードを、プロモーションとは別のストリームで送信します。キューで遅れることはありません。リトライも安全に処理されます。
支払いが成功した瞬間に購入を確認し、PDFの請求書を添付します。冪等キーを使えば、バックエンドからのリトライで領収書が重複することもありません。サポートは、後からどの領収書も見つけられます。
新しいデバイスからのログインや認証情報の変更をユーザーに通知します。配信イベントが記録されるため、各アラートがいつ送信され、バウンスしたかどうかを示せます。
配信済み、保留、バウンスのイベントを自社のデータベースに取り込めば、メールボックスを調べなくても、サポートやプロダクトの画面に実際のメールステータスを表示できます。エンジニアリングに届く問い合わせが減ります。
有効期限付きのサインインリンクとチーム招待を、分かりやすい文面と、新しいリンクを再リクエストする方法とともに送ります。
注文、チケット、リクエストの状態が変わったときに顧客へ通知し、配信イベントをそれに紐付けて記録します。
両方を同じ場所から送ること自体は問題ありません。1つのストリームに混在させると、配信の問題が始まります。
配信ストリームを分け、キャンペーンの問題がパスワードリセットを遅らせることがないようにしましょう。
バウンスや保留のメッセージを貼り付けると、分かりやすい言葉で理由、考えられる原因、推奨される対処を表示します。コパイロットは助言のみ行い、DNSや設定の変更はお客様のチームが実施します。
プロバイダーごとの通常の配信時間をモデルが学習し、ユーザーから問い合わせが来る前に異常な遅延を検知します。しきい値と通知先はお客様が決められ、アラートがルーティングを自動で変更することはありません。
MCP互換のインターフェースにより、承認済みのAIエージェントや社内ツールがメッセージの状態を照会したり、送信の下書きを作成したりできます。スコープ付きキーと人による承認ステップで、すべての操作をお客様の管理下に置けます。
領収書、パスワードリセット、アラートの文面について、お客様のトーンに合わせた初稿を生成します。チームメンバーが確認して最終テンプレートを承認するまで、保存も送信も行われません。
ここでのAI機能はあくまで支援です。提案、要約、フラグ付けを行い、送信や設定に関する判断はすべてお客様のチームが確認し、主導権を保ちます。
送信ドメインやIPプールを分けることで、キャンペーンの問題がパスワードリセットや領収書を遅延させたり、迷惑メールフォルダに振り分けさせたりするのを防ぎます。
すべての送信ドメインを認証し、From アドレスとの一致を確認します。レポートが問題なくなったら、DMARCを監視から強制適用へ移行しましょう。
イベントごとに一意のキーを付与し、タイムアウト後の再試行でも、同じ領収書やコードが顧客に二重に届かないようにします。
永続的な失敗を返すアドレスへの送信は停止し、急増時にはアラートを出しましょう。バウンスの繰り返しは、重要なメールの評判を損ないます。
プレーンテキストのパート、明確なアクション1つ、見覚えのある From 名を含めましょう。簡潔なメッセージはどこでも正しく表示され、フィッシングらしくも見えません。
メールストリームの分け方に迷っていますか?当社チームが一緒に構成を確認します。
トランザクションメールは、ユーザーの1回の操作をきっかけに送られ、領収書やリセットリンクなど本人が必要とする情報を届けます。マーケティングメールは販促目的でグループに送信されます。プロバイダーや規制での扱いが異なるため、ストリーム、ドメイン、IPプールを分けて運用してください。
自前のWebサーバーではなく、メールAPIか認証済みのSMTPリレーを使います。確認済みドメインから送信し、SPF、DKIM、DMARCを設定し、冪等性キーを使い、webhookを受信して、各メッセージが配信されたかバウンスしたかをアプリ側で把握できるようにします。
ドメインを認証し、一貫した送信元アドレスから送り、リセットメールをプロモーションと分け、短縮URLや大きな画像は避けます。プロバイダーごとの保留と苦情を監視すれば、特定のメールボックスプロバイダーがフィルタリングを始めても素早く対応できます。
ワンタイムコードのような時間に敏感なメッセージは、通常の状況なら数秒以内にメールボックスへ届くのが目安です。実際の速度は受信側のプロバイダーによって異なるため、プロバイダーごとに配信時間を追跡し、遅延時にアラートを出しましょう。処理の遅いプロバイダーにも対応できるよう、リセットリンクの有効期間は十分に長くします。
必ずしも必要ではありません。送信量が少ない場合は、適切に管理された共有プールで十分なことが多く、送信量が多い場合や業務上重要な場合は、ウォームアップと監視ができる専用IPが有利です。送信量、安定性、メッセージが遅れた場合の影響の大きさで判断してください。
はい。SMTPでもAPIでも、メッセージサイズの上限内であればPDFの請求書などを添付できます。ファイルは小さくするか、安全なダウンロードページへのリンクにしましょう。大きな添付は配信を遅くするため、公開前に実際の請求書でテストしてください。
配信済み、保留、バウンス、苦情のwebhookイベントを購読し、自社のレコードに紐づけて保存します。メッセージログでは、受信者またはメッセージIDで検索して、個々のメールの配信タイムライン全体をサポート担当者が確認できます。バウンスの急増にもアラートを設定しましょう。
AIはバウンスコードを分かりやすい言葉で説明し、異常な遅延を検知し、テンプレートの文面を下書きできます。あくまでアシスタントであり、提案はチームが確認し、送信に影響する変更はすべて承認してから適用されます。