QualisendのZapierネイティブアプリはまだありませんが、Zapierでもメールアドレスを検証できます。専用コネクターを探すのではなく、汎用のWebhooks by Zapierアクションを使うのがコツです。フォームやCRMがトリガーを起動し、Zapierが新しいアドレスをQualisend APIにPOSTし、FilterやPathsのステップが判定結果で処理を分岐させます。配信可能なアドレスだけがメールツールに流れ、リスクのあるアドレスは確認用に保留されます。このガイドでは、このZapを最初から最後まで構築します。
結論から#
現時点でインストールできるネイティブアプリはありません（ロードマップには入っています）。そのため、対応している方法は短いZapを組むパターンです。構成は次のとおりです。
- トリガー（新しいフォーム送信、新しいリード、新しい行など）
- メールアドレスを付けて検証APIを呼び出す「Webhooks by Zapier → Custom Request (POST)」アクション
- 最終的な判定結果を取得するDelayとWebhooks by Zapier → GETのステップ
- 返ってきた
statusを読み取って次の処理を決めるFilterまたはPathsのステップ
APIキーは公開フォームには置かず、Webhookのヘッダーにだけ設定してください。また、Webhookがエラーになった場合は、アドレスを通過させる設定にしておきます。一時的な不具合で本物のリードを取りこぼさないためです。
Zapierでメールアドレスを検証する2つの方法#
設定を始める前に、データにどの程度の鮮度が必要かに合わせて方式を選びます。
- リアルタイム、送信ごとに検証（Zap）。新しいアドレスが届いた時点で検証し、その場で振り分けます。このガイドの中心となる方法で、判定結果によって次の動きが変わる場合に向いています。たとえば、ダブルオプトインのメールを送るかどうかの判断、リードへのタグ付け、偽の登録の除外などです。
- バッチ、後からまとめて検証（CSV）。送信内容をシートやESPに溜めておき、定期的にエクスポートして一括検証ジョブにかけます。手順が簡単でアドレス単価も抑えられ、即時の判断は不要で送信前にリストをきれいにしたい場合に適しています。
多くのチームは両方を併用しています。リアルタイムの入口にはZapを置き、登録後に古くなったアドレスを拾うため、毎月リストのクリーニングを行う構成です。
ステップ1：トリガー#
アドレスを受け取るものをZapの起点にします。Zapierには、ほとんどのフォームツールやCRM向けのネイティブトリガーがあります。フォームアプリの「New Submission」、CRMの「New Lead」、Google Sheetsの「New Spreadsheet Row」などです。どれを選ぶ場合も、重要なのはメールアドレスを保持するフィールドが出力されることです。後続のステップでは、このフィールドを{{1.email}}のようなマージトークンとして参照します。
Webhookアクションは、何がトリガーであっても同じように動作します。そのため、Typeform、CRM、シートのどれをつなぐ場合でも、このガイドの手順は共通です。特定のトリガーに沿った手順の例はTypeformでメールアドレスを検証する方法で解説しており、そこから以降のステップに引き継げます。
ステップ2：Webhooks by ZapierでアドレスをPOSTする#
アクションのステップを追加し、Webhooks by ZapierのCustom Requestイベントを選びます。このステップが実際にQualisendを呼び出します。次のように設定してください。
| 項目 | 値 |
|---|---|
| Method | POST |
| URL | Qualisendの検証エンドポイントhttps://app.qualisend.com/api/v1/verify（リクエストとレスポンスの詳細はAPIリファレンスを参照） |
| Data Pass-Through? | No |
| Data | トリガーのメールフィールドを割り当てたemailキー1つだけのJSONボディ |
| Headers | Authorization: Bearer YOUR_API_KEYとContent-Type: application/json |
Data欄には生のJSONを入力でき、トリガーのメールトークンも埋め込めます。送信するボディは次のとおりです。
{ "email": "{{1.email}}" }
Zapierが代わりに送信するリクエストは、次のようになります。プレースホルダーは、開発者向けドキュメントを見て埋めてください。ドキュメントには正確なエンドポイントと、複数の言語によるリクエスト例が載っています。
POST https://app.qualisend.com/api/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{ "email": "jane@example.com" }
キーは、フルアクセスのキーではなく、このZap用に発行したスコープ付きキーを使ってください。Zapの履歴からキーが漏れても、呼び出せるのは検証APIだけで、アカウント、請求、チームの設定には触れられません。キーをフォームそのものやクライアント側のフィールドに置くのは厳禁です。キーを置いてよいのはWebhookのヘッダーだけで、これはZapier内のサーバー側で処理されます。
Test actionをクリックすると、Zapierがレスポンスボディを表示します。返ってくるのはjob_idとresultオブジェクトで、resultにはstatus、reasonコード、0～100のscore、sub_flagsのセット、smtpフィールドが入っています。新しいアドレスの場合は、通常おおよそ次のような内容が返ります。
{
"job_id": "8f3c9a2e-5b1d-4e7a-9c6f-2d8b1a4e7f30",
"probe_queued": true,
"result": {
"email": "jane@example.com",
"status": "unknown",
"score": 60,
"sub_flags": { "free_mail": false, "disposable": false, "role": false, "catch_all": false, "full_mailbox": false, "disabled": false },
"did_you_mean": null,
"smtp": "pending",
"reason": null
}
}
このunknownはまだ最終的な判定ではありません。レスポンスはすぐに返りますが、SMTPによるメールボックスのチェックはまだ実行中です。smtpはpendingで、チェックが終わるまでstatusは暫定のunknownのままです。smtpがcachedまたはskippedの場合（最近チェックしたアドレス、または即時チェックですでに結論が出たアドレス）は、resultが最終結果です。どちらの場合も、次のステップでジョブから最終的な判定結果を読み取るので、job_idトークンを控えておいてください。
ステップ3：最終的な判定結果を取得する#
分岐の前に、メールボックスのチェックが終わるまで待ちます。Delay by Zapier → Delay Forのステップで数分の待機を入れ、続けてGETイベントのWebhooks by Zapierアクションを追加します。クエリ文字列パラメーターにinclude=resultsを付けてジョブを指定し、Authorizationヘッダーは同じものを使います。
GET https://app.qualisend.com/api/v1/jobs/{{2.job_id}}?include=results
Authorization: Bearer YOUR_API_KEY
ここでの{{2.job_id}}は、POSTステップで返ったjob_idです。このステップはジョブを読み取るだけなので、アドレスを再度検証することも、追加のクレジットを消費することもありません。smtpがすでにcachedまたはskippedだった場合は、同じ最終結果がそのまま返ります。完了したチェックは、おおよそ次のようになります。
{
"id": "8f3c9a2e-5b1d-4e7a-9c6f-2d8b1a4e7f30",
"type": "single",
"status": "completed",
"results": [
{
"email": "jane@example.com",
"status": "deliverable",
"score": 93,
"reason": "accepted_email",
"sub_flags": { "free_mail": false, "disposable": false, "role": false, "catch_all": false, "full_mailbox": false, "disabled": false }
}
]
}
次のステップではこれらのフィールド名で分岐します。Zapierではたいていresults statusやresults sub_flags catch_allのようなトークンに展開されて表示されます。GETの実行時にチェックが終わっていない場合（たとえば受信側サーバーの応答が遅いときなど）は、results statusがqueuedまたはprocessingのままになります。これらはrisky、unknownと同じく確認用に回し、破棄しないでください。
各ステータスの意味と判定にいたる流れについては、メールアドレス検証の仕組みをご覧ください。
ステップ4：判定結果で分岐する#
検証結果を活用しなければ、クレジットが無駄になります。アドレスごとに処理を変えることが目的で、Zapierにはそのための方法が2つあります。
オプションA：Filter（最も簡単）。「良いアドレスだけを残したい」場合は、GETステップの後にFilter by Zapierのステップを追加します。条件は次のように設定します。
- Results Status（テキスト）でexactly matchesを選び、
deliverableを指定する
deliverable以外のアドレスはここでZapが止まり、確認済みのアドレスだけが後続のアクションに進みます。後続のアクションとは、ESPへの追加、コンタクトの作成、ウェルカムメールの送信などです。シンプルですが大雑把でもあり、risky、unknown、undeliverableをすべて同じ扱いにします。実際には、これらを別々に扱いたい場合が多いでしょう。
オプションB：Paths（結果ごとに振り分け）。 Zapierの有料プランで使えるPaths by Zapierを使うと、処理を別々のブランチに分けられます。各ブランチには専用の条件と後続のアクションを設定できます。
| Pathの条件 | 対応 |
|---|---|
Statusがdeliverable | コンタクトをESPまたはCRMに追加し、ファネルを進めます。 |
Statusがriskyまたはunknown、あるいはまだqueuedまたはprocessing | 「要確認」リストに追加するかタグを付けます。完全に除外はしないでください。このグループには、正確にプローブできないキャッチオールドメインも含まれます。 |
Statusがundeliverable | どこにも追加しません。必要に応じてシートに記録すると、フォーム項目の不具合や質の悪い流入元に気づけます。 |
サブフラグでも分岐できます。レピュテーションを重視するプロダクトでは、results sub_flags disposableがtrueのアドレスを、ステータスに問題がなくても確認用のパスに回す条件を追加してください。使い捨てアドレス、役割アドレス、フリーメールアドレスの扱いについては、役割アドレス・使い捨て・フリーメールの違いで解説している判断と同じ考え方です。Pathsは上から順に評価されるため、最も厳しいブランチを先頭に置きます。
Webhookのせいで優良なリードを逃さないようにする#
何よりも大事なルールは、フェイルオープンにすることです。Webhookのステップがエラーになったとき（APIが一時的に遅い、プランの上限に達した、ネットワークが一瞬不安定になったなど）に、Zap全体が止まって本物の登録を気づかないうちに失う事態は避けなければなりません。Zapierでは、Webhookアクションの設定を開き、「Continue on error」（プランによっては自動再実行やエラー処理のオプションとして表示されます）をオンにします。これはPOSTとGETの両方のステップで行ってください。そのうえで、判定結果のないアドレスはunknownとして扱い、破棄せずに後で確認できるよう保管するフォールバックを追加します。
検証APIは品質を確かめるフィルターであり、認証のゲートではありません。一時的な障害のために料金を支払っている顧客を弾くより、疑わしいアドレスを1件通してしまい、次回のリストのクリーニングで見つけるほうが、はるかに被害は小さくなります。サーバーレスでのサインアップ時検証でも同じフェイルオープンの考え方が使われており、プローブが遅くてもフォームを止めてはいけません。
Zapが向かない場合#
Zapierは連携のためのつなぎ役ですが、それなりのコストがかかります。検証するアドレスごとに1タスクを消費するため、送信ごとのWebhookは大量になると高くつき、即時の判断が不要なら過剰な構成になりかねません。次のような場合は、バッチ方式を選んでください。
- すでにあるリストをクリーニングする場合。新規の流入ではなく、過去の数千件のコンタクトが対象です。エクスポートして、一括ジョブを1回実行します。
- ボリュームが多く、タスク課金の負担が大きい一方で、毎晩または毎週のクリーニングでもデータの鮮度が足りる場合。
- Zapierの無料プランを使っていて、プレミアムのWebhooksアプリを利用できない場合。
この3つのケースではZapを使わず、フォームツール、シート、ESPから送信内容をCSVにエクスポートし、そのファイルをQualisendの一括検証にアップロードします。行ごとに同じstatus、score、サブフラグが得られ、クリーニング済みのファイルとしてダウンロードして再インポートできます。自動化を保守せずに、リストを健全に保ち、バウンス率を低く抑えられる、最も手間の少ない方法です。
ZapierのWebhookを使う方法と、自社のバックエンドからAPIを直接呼び出す方法のどちらにするか迷う場合は、APIの比較に両者のトレードオフをまとめています。Zapierは設定の速さで勝り、直接連携は規模が大きいときのコストと制御の面で勝ります。
よくある質問
01Zapier向けのQualisendネイティブアプリはありますか？
現時点ではありません。Qualisendのネイティブなプラットフォーム連携は再構築中のため、Zapierのディレクトリで検索できる専用アプリはまだなく、ロードマップに入っています。公開されるまでは、このガイドで説明しているとおり、汎用のWebhooks by ZapierアクションからQualisend APIを呼び出す方法が、Zapierでメールアドレスを検証する正式な方法です。Webhookを使う方法は柔軟性も高く、リクエスト、ヘッダー、分岐ロジックを自分で制御できます。
02Zapierの有料プランは必要ですか？
リアルタイムのZapでは、事実上必要です。Webhooks by Zapierはプレミアムの組み込みアプリで、複数ステップのZapとPathsはZapierの有料プランが必要なため、判定結果で分岐するフローには有料プランが求められます。無料プランの場合は、CSVをエクスポートして一括検証する方法を使ってください。Zapもプレミアムアプリも不要で、ファイルをアップロードするだけで済みます。
03メールツールにはどのステータスを通すべきですか？
厳格に絞るならdeliverableのみです。より多くのアドレスを残したい場合は、deliverableに加えてriskyとunknownも許可しつつ、これらはメインのフローではなく、優先度の低い別のセグメントに回してください。riskyの多くは、実際には届く可能性のあるキャッチオールドメインです。undeliverableは常に除外します。レピュテーションを重視するプロダクトでは、disposableサブフラグでの分岐も検討してください。
04Zapを有効にする前に、どうテストすればよいですか？
Webhookの各ステップでZapier組み込みのTest actionを使い、問題のないアドレスと不正なアドレスを1件ずつ試します。POSTステップはメールボックスのチェック中にunknownと表示されることがあります。そのため、チェックが終わるまで少し待ったGETステップで、最終的なstatusが想定どおりに変わることを確認してください。そのうえで、FilterやPathsの条件が各結果を正しいブランチに振り分けるかを確かめます。Zapierの外でアドレスを1件だけ手早く確認するには、無料メールチェッカーにアドレスを貼り付け、Zapの結果と判定を見比べてください。
構築の準備はできましたか。スコープ付きキーと正確なリクエスト形式は開発者向けドキュメントで入手できます。アドレスの簡単な確認には無料メールチェッカーが使えます。そして無料プランから始めましょう。100クレジットあれば、Zap全体を構築し、不正なアドレスがリストに届く前に除外される様子を確認できます。
