Make（旧Integromat）でも、アプリ内にQualisend専用のモジュールがまだなくても、今日からメールアドレスを検証できます。汎用のHTTPモジュールを中心にシナリオを組むのが基本の方法です。新しいアドレスが届くとトリガーが起動し、HTTPリクエストがそのアドレスをQualisend APIにPOSTします。続くRouterまたはFilterが判定結果を読み取ってフローを分岐させ、配信可能なアドレスだけがESPやCRMに進み、リスクのあるアドレスや配信不能なアドレスは保留されます。このガイドでは、このシナリオを最初から最後まで構築します。
結論から#
現時点でインストールできるネイティブアプリはありません（ロードマップには入っています）。そのため、対応している方法は3つの部品で構成するシナリオです。
- トリガー（新しいフォーム送信、新しい行、またはフォームの送信先に指定するcustom webhook）
- メールアドレスを付けて検証APIを呼び出すHTTP → Make a requestモジュール
- 返ってきた
statusを読み取って次の処理を決める、ルートごとのフィルター付きRouter
レスポンスでメールボックスのチェックがまだpendingと示されている場合は、短いSleepを入れてから、返されたジョブにGETを送り、最終的な判定結果を先に取得します。APIキーはモジュールのヘッダーにだけ設定し、公開フォームのフィールドには置かないでください。また、APIがエラーを返した場合でもHTTPモジュールが処理を続けるように設定しておきます。一時的な不具合で本物のリードを取りこぼさないためです。
Makeでメールアドレスを検証する2つの方法#
設定を始める前に、データにどの程度の鮮度が必要かに合わせて方式を選びます。
- リアルタイム、送信ごとに検証（シナリオ）。新しいアドレスが届いた時点で検証し、その場で振り分けます。このガイドの中心となる方法で、判定結果によって次の動きが変わる場合に向いています。たとえば、ダブルオプトインのメールを送るかどうかの判断、リードへのタグ付け、偽の登録の除外などです。
- バッチ、後からまとめて検証（CSV）。送信内容をシートやESPに溜めておき、定期的にエクスポートして一括検証ジョブにかけます。手順が簡単でアドレス単価も抑えられ、即時の判断は不要で送信前にリストをきれいにしたい場合に適しています。
多くのチームは両方を併用しています。リアルタイムの入口にはシナリオを置き、登録後に古くなったアドレスを拾うため、毎月リストのクリーニングを行う構成です。
ステップ1：トリガー#
アドレスを受け取るものをシナリオの起点にします。Makeには数百のトリガーモジュールがあります。フォームアプリの「Watch Responses」、Google SheetsやAirtableの「Watch Rows」、CRMの「New Lead」などです。使っているフォームツールにMake専用のモジュールがない場合は、最初のモジュールとしてCustom webhookを置き、フォームのWebhook URLをそれに向けます。MakeがユニークなURLを発行し、最初の送信が届くと、受信したデータの構造が表示されます。
どれを選ぶ場合も、重要なのはメールアドレスを保持するフィールドが出力されることです。後続のモジュールは、このフィールドをマッピングされたトークンとして参照します。Makeでは、トリガーの出力バンドルから取り出した値が色付きのピルとして表示され、フィールドにクリックで挿入できます。以下の例では、このトークンを{{1.email}}と表記しています。1はトリガーのモジュールを指します。
ステップ2：HTTPモジュールでアドレスをPOSTする#
モジュールを追加し、HTTP → Make a requestを選びます。このステップが実際にQualisendを呼び出します。次のように設定してください。
| 項目 | 値 |
|---|---|
| URL | 検証エンドポイント。たとえばhttps://app.qualisend.com/api/v1/verify（正確なパスはAPIリファレンスで確認してください） |
| Method | POST |
| Headers | Authorization: Bearer YOUR_API_KEYとContent-Type: application/json |
| Body type | Raw、コンテンツタイプはJSON (application/json) |
| Request content | トリガーのメールのピルを割り当てたemailキー1つだけのJSONボディ |
| Parse response | Yes：後続のモジュールが返されたフィールドを直接マッピングできるようにします |
Parse responseをオンにすると、MakeがJSONのレスポンスを生の文字列ではなく、マッピング可能なフィールドとして読み込みます。Request content欄にボディを入力し、トリガーのメールのピルを埋め込みます。
{ "email": "{{1.email}}" }
Makeが代わりに送信するリクエストは、次のようになります。プレースホルダーは、開発者向けドキュメントを見て埋めてください。ドキュメントには正確なエンドポイントと、複数の言語によるリクエスト例が載っています。
POST https://app.qualisend.com/api/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{ "email": "jane@example.com" }
キーは、フルアクセスのキーではなく、このシナリオ用に発行したスコープ付きキーを使ってください。シナリオの実行履歴からキーが漏れても、できるのはアドレスの検証と結果の読み取りだけで、それ以外には触れられません。キーをフォームそのものやクライアント側のフィールドに置くのは厳禁です。キーを置いてよいのはHTTPモジュールのヘッダーだけで、これはMake内のサーバー側で処理されます。
Run onceをクリックすると、Makeがレスポンスのバンドルを表示します。返ってくるのはjob_idとresultオブジェクトで、resultにはstatus、reasonコード（メールボックスのチェックが終わるまではnull）、0～100のscore、sub_flagsのセット、メールボックスのチェックが完了したかを示すsmtpフィールドが入っています。構文チェックとドメインチェックを通過した新しいアドレスは、通常おおよそ次のような内容が返ります。
{
"job_id": "b7e4c2a0-1d3f-4e8a-9c6b-2f5a8d0e7c41",
"result": {
"status": "unknown",
"reason": null,
"score": 61,
"smtp": "pending",
"sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
}
}
次のステップではこれらのフィールド名で分岐します。Makeがどうマッピングするかを押さえておいてください。フィルターではresult: status、result: score、および個々のsub_flagsを参照します。各ステータスの意味と判定にいたる流れについては、メールアドレス検証の仕組みをご覧ください。
メールボックスのチェックがまだpendingの場合#
smtpは、resultが最終結果かどうかを示します。cachedまたはskippedなら最終結果なので、そのまま振り分けられます。新しいアドレスで多いpendingは、SMTPによるメールボックスのチェックがまだ実行中で、statusは暫定のunknownであることを意味します。そのアドレスに対して/verifyをもう一度呼び出さず、代わりにそのジョブを取得してください。
- HTTPモジュールの直後にRouterを追加し、2つのルートを作ります。1つは
result: smtpがpendingと等しいルート、もう1つはそれ以外すべてを受けるフォールバックのルートです。 pendingのルートに、ToolsにあるSleepモジュールを追加し、約60秒に設定します。- その後ろに2つ目のHTTP → Make a requestモジュールを置きます。メソッドは
GET、URLはhttps://app.qualisend.com/api/v1/jobs/{{2.data.job_id}}?include=results（2はPOSTのモジュール）、Authorizationヘッダーは同じものを使い、Parse responseをオンにします。
チェックが完了すると、ジョブ自体のstatusがcompletedになり、最終的な判定結果はresults配列の最初の項目に入ります。配信可能なアドレスの場合は、おおよそ次のようになります。
{
"status": "completed",
"results": [
{
"email": "jane@example.com",
"status": "deliverable",
"reason": "accepted_email",
"score": 92,
"sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
}
]
}
GETの実行時にチェックがまだ終わっていない場合（グレーリスティングを行うサーバーでは、数分間チェックが保留されることがあります）、ジョブとその項目はpendingまたはprocessingのままです。次のステップでは、これらを破棄せず確認用に回します。このステップから出る2つのルートは、最終的に同じ判定結果のルートにつながります。pendingのルートではGETのresultsの最初の項目からstatusを読み取り、フォールバックのルートではPOSTのresult: statusから読み取ります。
ステップ3：Routerで判定結果ごとに分岐する#
検証結果を活用しなければ、クレジットが無駄になります。アドレスごとに処理を変えることが目的で、MakeではそのためにRouterモジュールを使います。
前のステップの各ルートの末尾（pendingのルートではGETの後）にRouterを置くと、必要な数のルートに分岐します。各ルートには、Routerから出る線のレンチをクリックして、最終的なstatusを判定する専用のフィルターを設定します。
| ルートのフィルター | 対応 |
|---|---|
Status equals deliverable | コンタクトをESPまたはCRMに追加し、ファネルを進めます。 |
Status equals riskyまたはunknown | 「要確認」リストに追加するかタグを付けます。完全に除外はしないでください。このグループには、正確にプローブできないキャッチオールドメインも含まれます。 |
Status equals undeliverable | どこにも追加しません。必要に応じてシートに記録すると、フォーム項目の不具合や質の悪い流入元に気づけます。 |
Makeはルートを左から右へ評価します。ルートをfallback（フィルターのないルート）に指定しない限り、条件に一致するルートはすべて実行されます。そのため、1つのアドレスが2つのブランチに流れないよう、statusについての条件は互いに排他的にしてください。fallbackに指定するのはundeliverableのルートではなく、確認用のルートです。こうすると、チェックがまだpendingやprocessingのアドレスも破棄されずに確認用に入り、分類されないまま漏れるものがなくなります。
サブフラグでも分岐できます。レピュテーションを重視するプロダクトでは、sub_flags: disposableがtrueのときも、ステータスに問題がなくても確認用のルートに回る条件を追加してください。使い捨てアドレス、役割アドレス、フリーメールアドレスの扱いについては、役割アドレス・使い捨て・フリーメールの違いで解説している判断と同じ考え方です。Routerの1つのフィルターには複数のAND/OR条件を設定できるため、1つのルートでstatusの条件とsub_flagsの条件を組み合わせられます。
HTTPモジュールのせいで優良なリードを逃さないようにする#
何よりも大事なルールは、フェイルオープンにすることです。HTTPモジュールがエラーになったとき（APIが一時的に遅い、プランの上限に達した、ネットワークが一瞬不安定になったなど）に、シナリオ全体が止まって本物の登録を気づかないうちに失う事態は避けなければなりません。POSTとGETの各HTTPモジュールを右クリックし、Add error handlerを選んで、statusをunknownにしたデフォルトのバンドルを渡すResumeディレクティブを設定します。これでシナリオは、アドレスを破棄せず「後で確認」として扱う経路を通って処理を続けます。（シナリオのエラー処理をstore incomplete executionsに設定すると、失敗した実行が消えずに再試行用のキューに入ります。）
検証APIは品質を確かめるフィルターであり、認証のゲートではありません。一時的な障害のために料金を支払っている顧客を弾くより、疑わしいアドレスを1件通してしまい、次回のリストのクリーニングで見つけるほうが、はるかに被害は小さくなります。サーバーレスでのサインアップ時検証でも同じフェイルオープンの考え方が使われており、プローブが遅くてもフォームを止めてはいけません。
シナリオが向かない場合#
Makeは連携のためのつなぎ役ですが、それなりのコストがかかります。検証するアドレスごとにオペレーションを消費するため、送信ごとのHTTP呼び出しは大量になると積み上がり、即時の判断が不要なら過剰な構成になりかねません。次のような場合は、バッチ方式を選んでください。
- すでにあるリストをクリーニングする場合。新規の流入ではなく、過去の数千件のコンタクトが対象です。エクスポートして、一括ジョブを1回実行します。
- ボリュームが多く、オペレーション課金の負担が大きい一方で、毎晩または毎週のクリーニングでもデータの鮮度が足りる場合。
- たまに実行すれば済む作業のために、常時稼働するシナリオを保守したくない場合。
この3つのケースではシナリオを使わず、フォームツール、シート、ESPから送信内容をCSVにエクスポートし、そのファイルをQualisendの一括検証にアップロードします。行ごとに同じstatus、score、サブフラグが得られ、クリーニング済みのファイルとしてダウンロードして再インポートできます。自動化を保守せずに、リストを健全に保ち、バウンス率を低く抑えられる、最も手間の少ない方法です。
MakeのHTTPを使う方法と、自社のバックエンドからAPIを直接呼び出す方法のどちらにするか迷う場合は、APIの比較に両者のトレードオフをまとめています。Makeのシナリオは設定の速さで勝り、サーバーも不要です。直接連携は、規模が大きいときのコストと制御の面で勝ります。同じHTTPモジュールの構成は、Makeのオペレーション課金が負担になった場合の移行先として、セルフホストのn8nワークフローにもそのまま移せます。
よくある質問
01Make向けのQualisendネイティブモジュールはありますか？
現時点ではありません。Qualisendのネイティブなプラットフォーム連携は再構築中のため、Makeのモジュール一覧で検索できる専用アプリはまだなく、ロードマップに入っています。公開されるまでは、このガイドで説明しているとおり、汎用のHTTP → Make a requestモジュールからQualisend APIを呼び出す方法が、Makeでメールアドレスを検証する正式な方法です。HTTPを使う方法は柔軟性も高く、リクエスト、ヘッダー、ルーティングのロジックを自分で制御できます。
02メール1件あたり、シナリオは何オペレーションを使いますか？
実行されるモジュール1つにつき、おおよそ1オペレーションです。トリガー、HTTPリクエスト、Routerで実行されたルートがそれぞれ1つに数えられます。そのため、検証する送信1件で数オペレーション、1,000件なら数千オペレーションとなり、多くのMakeの有料プランに十分収まります。ボリュームが多くてオペレーション課金が負担になる場合は、そのトラフィックをCSVエクスポートと一括検証の方法に切り替えてください。オペレーションはまったく使いません。
03メールツールにはどのステータスを通すべきですか？
厳格に絞るならdeliverableのみです。より多くのアドレスを残したい場合は、deliverableに加えてriskyとunknownも許可しつつ、これらはメインのフローではなく、優先度の低い別のセグメントに回してください。riskyの多くは、実際には届く可能性のあるキャッチオールドメインです。undeliverableは常に除外します。レピュテーションを重視するプロダクトでは、disposableサブフラグでの分岐も検討してください。
04シナリオを有効にする前に、どうテストすればよいですか？
MakeのRun onceボタンで、問題のないアドレスと不正なアドレスを1件ずつ試し、HTTPモジュールの吹き出しに返されたstatusが表示されるのを確認します。問題のないアドレスでも、POSTでは通常smtpがpendingで返るため、最終的な判定結果はSleepの後のGETに表示されます。そのうえで、入力ごとに正しいRouterのルートが点灯することを確かめます。Makeの外でアドレスを1件だけ手早く確認するには、無料メールチェッカーにアドレスを貼り付け、シナリオの結果と判定を見比べてください。
構築の準備はできましたか。スコープ付きキーと正確なリクエスト形式は開発者向けドキュメントで入手できます。アドレスの簡単な確認には無料メールチェッカーが使えます。そして無料プランから始めましょう。100クレジットあれば、シナリオ全体を構築し、不正なアドレスがリストに届く前に除外される様子を確認できます。
