返信や受信メッセージを、アプリケーションが処理できる構造化イベントに変換します。
AIによる意図分類が、返信、不在通知、苦情を自動で仕分けします。
選択したサブドメインのMXレコードをMigoSMTPに向けます。
ヘッダー、本文、添付ファイルが整った構造で届きます。
宛先アドレスごとに異なるエンドポイントへ振り分けます。
ご自身で設定できるサイズ上限付きでファイルを受信します。
受信メールをアプリに届く前にスクリーニングします。
各ペイロードが当社から送られたものであることを検証できます。
サブドメインのMXレコードを公開します。
アドレスパターンを指定し、webhookを選びます。
アプリが各メッセージをJSONで受け取ります。
ステージを切り替えて、各段階でコントロールできる内容を確認できます。イメージ画面です。表示されている数値とアドレスはすべてサンプルデータです。
受信ルートを使って、トランザクションメールへの返信を取得したり、チケットを作成したり、ワークフローに連携したりできます。
受信メール解析とは、ドメイン宛てに送られたメールを受け取り、アプリケーションが使える構造化データに変換する処理です。MigoSMTPでは、サブドメインのMXレコードを公開し、アドレスパターンに一致するルートを作成するだけで、各メッセージがヘッダー、テキスト、HTML、添付ファイル情報を解析済みのJSONとしてwebhookに届きます。他のイベント機能とほぼ同じ仕組みなので、既存のwebhook処理コードをそのまま再利用できることも多くあります。
メールサーバーを運用せずに、返信や受信メールに対応したい開発者向けの機能です。代表的な用途は、チケットを作成するサポート受信箱、トランザクションメールの返信トラッキング、メールで書類をアップロードするといったメールからアプリへの機能です。ルーティングルールで宛先アドレスごとに異なるエンドポイントへ振り分けられ、各配信には署名が付くため送信元を検証できます。検索可能な受信ログでは、メッセージの検索、エンドポイントに送られたペイロードの確認、処理に失敗した場合の再送が行えます。
返信への対応は到達率にとって重要です。本物の返信は強力なエンゲージメントシグナルであり、no-replyアドレスに届いた未読のバウンスや苦情は見逃されてしまいます。これらを取得すれば、素早く対応できます。AIによる意図分類は、受信メッセージを返信、不在通知、配信停止リクエスト、苦情に仕分けでき、システムが適切に対応できるようになります。また、返信からはどのアドレスが有効かが分かり、リストを長期的にクリーンに保つ助けとなるほか、受信者が何を伝えたかの記録にもなります。webhookやログと組み合わせれば、受信ルートによって、送信したメールと返ってくる内容の流れが一巡します。
返信用サブドメインのsupport@をヘルプデスクのエンドポイントに振り分けます。メールボックスをポーリングしなくても、各メールが送信者、件名、添付ファイル付きのチケットになります。
返信用サブドメインに、アドレス内にトークンを含めたReply-Toを設定します。誰かが返信すると、受信メールのルーティングが、その返信を該当する注文や会話に紐付けます。
ユーザーが請求書や書類を専用アドレスに転送できるようにします。解析済みの添付ファイルが、設定したサイズ上限の範囲内で、保存や処理ができる状態でエンドポイントに届きます。
返信で届く不在通知や配信停止リクエストを取得し、コンタクトのステータスを自動更新します。停止を求めた相手へのメール送信を止められます。
返信用サブドメイン上に、顧客またはプロジェクトごとの専用アドレスを割り当てます。転送された契約書や請求書は解析済みの添付ファイルとして届き、自動で整理できます。
no-replyや不正利用報告用のアドレスに届いた返信を自社のワークフローに振り分け、本物の苦情が見逃されず、担当者に読まれるようにします。
どちらもメールを受け取れます。違いは、その仕組みを誰が保守するかです。
受信専用のサブドメインを使えば、通常のメールボックスに影響しません。
受信メッセージは、本物の返信、不在通知、配信停止リクエスト、苦情、営業問い合わせとしてラベル付けできます。ラベルをルートに対応付け、確信度の低いものは担当者に回します。
サポートルートでは、アシスタントがナレッジベースをもとに返信を下書きします。担当者が確認して送信し、ご自身でそのルールを設定しない限り、自動で送信されることはありません。
長い返信の連なりを短い要約と次のアクション案にまとめ、担当者がすぐに会話を引き継げるようにします。元のメッセージはログに残ります。
AIリスクスコアリングが、疑わしい受信メッセージを評価し、スパム・ウイルスチェックを補完します。高リスクのものを隔離するか、フラグを付けるか、そのまま配信するかは、お客様が選べます。
AI機能はあくまで補助です。分類とドラフトはワークフローを支援するもので、ルーティングルールと送信内容はお客様が決定します。
MXレコードはreply.yourdomain.comのようなサブドメインに置くと、通常のメールボックスが引き続き使え、受信トラフィックも分離されます。
ペイロードを処理する前に署名ヘッダーを確認してください。公開URLには誰でもPOSTできるため、署名のないリクエストは信頼しないでください。
成功レスポンスを素早く返し、処理はキューに回します。ハンドラーが遅いと、リトライや重複配信の原因になります。
リトライにより同じメッセージが2回届くことがあります。メッセージIDで重複を排除すれば、ログからの再送でチケットが重複して作られることはありません。
ルートごとに最大サイズと許可するファイルの種類を決めましょう。サイズ超過や想定外のファイルを早い段階で拒否すれば、下流のシステムを守れます。
各ペイロードの識別子を、自社のレコードと並べて保存します。再送、サポートでの照会、重複排除が簡単になります。
サポート受信箱や返信ワークフローをご検討中ですか?当社チームが設定を一緒に確認します。
受信メール解析は、お客様が管理するアドレス宛てのメールを受け取り、送信者、件名、本文、添付ファイルを含む構造化データ(通常はJSON)に変換する仕組みです。アプリケーションはwebhookでそれを受け取るため、メールサーバーを運用せずにメッセージへ対応できます。
受信ドメインを追加し、サブドメインのMXレコードを公開して、アドレスパターンに一致するルートを作成し、HTTPSのwebhookに向けます。受信した各メッセージは、署名付きJSONとしてそのエンドポイントにPOSTされます。
通常のメールに影響しないよう、専用のサブドメインをお勧めします。MXレコードはその名前宛てのすべてのメールを受信サービスに送るため、ルートドメインを使うと通常のメールボックスが転送されてしまいます。
配信はリトライされ、エンドポイントが復旧したら受信ログから再送できます。成功レスポンスは、ペイロードを確実に受け取ってから返してください。ハンドラーを冪等にしておけば、再送された配信が2回目に何かを変更することはありません。
ペイロードには各添付ファイルの情報が記載されます。サイズと種類の上限はルートごとに設定するため、アプリが受け付ける内容はお客様が決められます。実際のファイルでいくつかテストして、ハンドラーでの扱い方を確認し、ルートごとに厳しい上限を設定してください。
受信メールは、お客様宛てに送られたメッセージを処理し、エンドポイントにPOSTします。webhookはより広く、配信済みやバウンスなど、送信したメッセージに関するイベントを通知します。受信メールは配信手段としてwebhookを使うため、同じ署名チェックが適用されます。
有効にした場合のみです。AI分類と要約は、オンにしたルートでのみ実行され、結果はお客様ご自身のルールに対応付ける提案として扱われます。どのメッセージも担当者が確認できます。
はい。受信メールはアプリに届く前にスクリーニングでき、フラグが付いたメッセージを拒否するか、タグを付けるか、確認のために保留するかを選べます。すべての判定はログに記録されるため、処理内容を監査できます。