Zapierで メールを 検証する 方法
Zapierはマーケティングリストにデータを送り込むフォーム、CRM、メールツールをつなぐため、誰にも気づかれないうちに不正なアドレスが入り込む場所でもあります。VeriMails APIをZapに組み込めば、新しい連絡先が届いた瞬間にすべて検証し、結果に応じて自動で振り分けられます。このガイドでは、そのリアルタイム検証ワークフローの作り方を紹介します。
要約
Zapier設定 チェックリスト
リクエストステップを追加する前に、メールのフィールドがどこに出てくるか、VeriMailsの各結果で何をするかを正確に決めておきましょう。振り分けの計画が明確なら、未検証の連絡先がZapから他のアプリに送られるのを防げます。
| 判断項目 | Zapierの設定 | 運用メモ |
|---|---|---|
| トリガーデータ | フォームの送信、リード広告、CRMのリード、スプレッドシートの新しい行など、元のメールアドレスを取得できる最初のトリガーを使います。 | 取得直後に検証すれば、同じアドレスが後続のすべてのアクションに広がるのを防げます。 |
| APIステップ | Webhooks by ZapierまたはAPI Requestアクションを使い、トリガーのメールをリクエストにマッピングし、VeriMailsのAPIキーを含めます。 | このステップは、連絡先の作成や購読者の追加といったアクションより前に置きます。エンドポイントの設定についてはメール検証API ガイドをご覧ください。 |
| 振り分けの種類 | 有効な連絡先だけを先に進めたい場合はFilterを使います。有効、無効、使い捨て、キャッチオールで分岐させたい場合はPathsを使います。 | Filterは停止ゲートです。停止した側の分岐でログ、アラート、クリーンアップのタスクが必要な場合はPathsが適しています。 |
| 確認先 | 保留した行は、アドレス、ステータス、理由、元のソースとともに、シート、CRMのメモ、チームへの通知に送ります。 | 確認ログがあれば、ノイズの多いリードソースを特定し、フォームにより強い入力チェックが必要かを判断できます。 |
| テストデータ | Zapをオンにする前に、有効、無効、使い捨て、キャッチオールに当たると分かっているテストアドレスで実行します。 | Zapが実際のリードの処理を始める前に、すべての分岐が想定どおりに動くことを確認しましょう。 |
Zapierの 連絡先を 検証すべき理由
Zapierはスタックの中心に位置し、連絡先を取得した場所から使われる場所へと移動させます。その中心的な位置こそが、検証に最適な場所である理由です。Zapの中で不正なアドレスを見つければ、他のツールに届く前に止められます。
Zapは 連絡先を 課金・送信を 行う システムに 直接送り込む
一般的なZapは、新しいフォームの送信やCRMのリードを受け取り、メールプラットフォーム、広告オーディエンス、セールスシーケンスに送り込みます。その連絡先が無効なら、不正なアドレスが課金対象になるか送信対象になるシステムに入ってしまいます。作成や追加のステップより前にZapの中で検証すれば、後続のすべてのアプリをクリーンに保てます。
フォームや リード 広告の トリガーは 不正な データが 最も 多い
新しいフォーム入力、ランディングページの送信、リード広告など、最も一般的なZapのトリガーは、メールデータのノイズが最も多いソースでもあります。フォームでは入力ミス、放置、偽のアドレスが絶えず発生します。トリガーの出力に検証ステップを置けば、自動化の入口でこうしたエラーを捕捉できます。
リアルタイム 検証は 定期的な クリーンアップに 勝る
Zapの中で検証すれば、連絡先は数週間後の四半期ごとのエクスポートではなく、届いた瞬間にチェックされます。新しい行が後続のすべてのアプリに広がる前に振り分けられるため、四半期ごとのクリーンアップだけに頼るよりもバウンスの急増を防ぎやすくなります。
不正な アドレスは 後続の リスクを 生み続ける
フォームとインボックスの間にどれだけ多くのツールがあっても、無効なアドレスはいずれバウンスする可能性があります。一般的な運用上の目安を超えるバウンス率は、今後のキャンペーン全体でフィルタリングされやすくなる原因になります。ZapにVeriMailsのステップを入れれば、後でメールプラットフォームに負担させるのではなく、発生源でそのリスクを減らせます。
VeriMailsが チェックする 項目
Zapが連絡先についてVeriMails APIを呼び出すと、VeriMailsは多層的なチェックを実行し、Zapで分岐に使える構造化された結果を返します。各アドレスのテスト内容は次のとおりです。
構文検証で、アドレスの形式が正しいかを確認します。 MXとDNSレコードを照会し、ドメインが存在してメールを受信できることを確認します。ライブのSMTPハンドシェイクでは、受信側のメールサーバーに接続し、何も送信せずに、そのメールボックスがメールを受け付けるかを確認します。キャッチオール検出は、送られたすべてのアドレスを受け付けるドメインを特定します。使い捨ての検出は、一時的な受信箱のドメインを検出します。ロールベースの検出は、info@、sales@、support@ のような汎用アドレスを特定します。
VeriMailsは、リアルタイムのZapステップに適した明確な検証結果を返します。キャッチオールドメインは曖昧なスコアではなく明確な検出結果として報告されるため、FilterやPathsのロジックで意図的に扱えます。
Zapier ユーザー 向けの 料金
リアルタイム検証のZapは新しい連絡先が届くたびにVeriMailsのクレジットを消費するため、実際に検証したアドレスの分だけ支払います。クレジットパックは1件あたり$0.0019からで、10,000クレジットは$19です。より大きなクレジットパックは最大5,000,000アドレスで$1,499まで拡張でき、大量の自動化にも対応します。
新しい連絡先が安定して届き、毎月一定の請求を希望する場合は、年払いプランを年間請求で月額$12.50からご利用いただけます。新規アカウントには登録時にクレジットカード不要で100クレジットが無料で付き、クレジットに有効期限もないため、導入前にZapを作ってテストするのも簡単です。
ワークフローの 図解
Zapが他のアプリに連絡先を書き込む前に、検証ステップとしてVeriMailsを追加するには、このフローを使います。
ステップバイステップ
新しい 連絡先を 取得する トリガーを 設定する
新しいZapを作成し、新しいフォームの送信、CRMの新しいリード、新しいリード広告、スプレッドシートの新しい行など、連絡先をワークフローに取り込むトリガーを選びます。このトリガーが、Zapの後続ステップで検証・振り分けするメールアドレスを生成します。
VeriMails APIを 呼び出す ステップを 追加する
Webhooks by ZapierのGETまたはPOSTメソッド、あるいはAPI Requestアクションを使ってアクションステップを追加します。VeriMailsの検証エンドポイントを指定し、トリガーのメールフィールドをリクエストに渡して、VeriMailsのAPIキーを含めます。ZapierがJSONレスポンスを解析するため、検証結果を後のステップで使えるようになります。
結果に 応じて 分岐する Filterまたは Pathsの ステップを 追加する
VeriMailsの結果が有効の場合だけ続行するよう設定したFilterステップを挿入するか、Pathsで結果ごとに個別に処理します。Pathsを使えば、有効な連絡先は1つの分岐へ、無効、使い捨て、キャッチオールの連絡先は別の分岐へ送り、確認や配信停止に回せます。
有効な 連絡先を 送信先の アプリに 送る
有効の分岐で、メールプラットフォーム、CRM、広告オーディエンスに連絡先を追加または更新するアクションを追加します。このステップに届くのは最近チェックした有効なアドレスだけなので、後続のリストやオーディエンスに明らかに無効な行が入るのを防げます。
不正な アドレスを 処理して Zapを オンに する
配信不能の分岐では、配信不能と使い捨てのアドレスをスプレッドシートや通知に記録し、傾向を確認して必要に応じてフォローアップできるようにします。いくつかのサンプルアドレスでZapをテストし、各分岐が正しく動くことを確認してからZapをオンにすれば、新しい連絡先はすべてリアルタイムで検証されます。
結果 ごとの 対応
VeriMailsのレスポンスは、単なるメモではなく振り分け用のデータとして使いましょう。最も安全なZapは、配信可能と明確に判断できないアドレスをすべて止めるか迂回させます。
- 配信可能: CRM、メールプラットフォーム、広告オーディエンス、セールスツールへ進め、送信先のアプリがカスタムフィールドに対応していれば検証日を追加します。
- 配信不可:連絡先追加のステップの前でZapを止め、アドレスを配信停止用またはクリーンアップ用のシートに記録します。
- キャッチオール:確認用の分岐に回します。ドメインはメールを受け付けますがメールボックスは確認されていないため、これらの連絡先は大量の自動送信から外しておきます。
- 使い捨て:ナーチャリングやライフサイクルのキャンペーンから除外し、チームが意欲の低い登録パターンを調べられるよう元のソースにタグを付けます。
- ロールベース:サポートや請求などのチーム用インボックスを対象にしたワークフローでない限り、手動の分岐に送ります。
- APIエラー:未検証のまま連絡先を先に送らず、一時停止するかアラートを出します。チェックの失敗が、知らないうちに承認済みのリードにならないようにしましょう。