n8nで
n8n のワークフローは、マーケティングを支えるフォーム、データベース、メールツールの間でコンタクトを受け渡すため、不正なアドレスを早い段階で捕捉するのに最適な場所です。HTTP Request ノードを使えばワークフローの途中で VeriMails API を呼び出し、届いたコンタクトをすべて検証し、IF ノードで結果ごとに振り分けられます。このガイドでは、n8n Cloud でもセルフホストでも使える構築手順を説明します。
要約
n8n ワークフロー
HTTP Request ノードが検証のチェックポイントになるようワークフローを構築します。次に何をするかは、VeriMails の JSON レスポンスをもとにルーティング用のノードが判断します。
| 判断項目 | n8n の設定 | 運用メモ |
|---|---|---|
| 入力ノード | 最初にメールの値を受け取る Webhook ノード、フォームトリガー、データベーストリガー、またはシートのトリガーを使います。 | 下流のノードがコンタクトを CRM や送信ツールに書き込む前に検証します。 |
| API 認証情報 | VeriMails のキーを HTTP Request の認証情報として保存し、API の設定に応じてヘッダー認証またはクエリ認証を使います。 | 認証情報を使えばキーがワークフローの項目に平文で残らず、セルフホストでも Cloud でもキーのローテーションが簡単になります。 |
| HTTP Request ノード | メソッドと URL を VeriMails APIに合わせて設定し、トリガーのアイテムから式でメールをマッピングします。 | ルーティング用のノードをつなぐ前に、ノードを一度実行して出力の JSON を確認します。 |
| 分岐ノード | 配信可能かどうかの単純な振り分けには IF を、キャッチオール、使い捨て、ロールベースの結果を別々に出力したい場合は Switch を使います。 | Switch を使うと、複数ステータスのルーティングが読みやすくなり、後から安全に拡張できます。 |
| 失敗時の動作 | API の呼び出しが失敗したり想定外のステータスが返ったりした場合に、入力とレスポンスを記録するエラー用またはフォールバック用の分岐を追加します。 | 安全側に倒して停止させ、ノードの設定が変わっただけで未検証のアドレスが先に進まないようにします。 |
n8n の
n8n は、コンタクトのソースと、それを保存・送信するツールをつなぐ自動化レイヤーです。そこに検証ノードを追加すれば、不正なアドレスを1か所で一度だけ捕捉でき、つながっているすべてのシステムに広がるのを防げます。
ワークフローは、
一般的な n8n のワークフローは、新しいフォーム送信やデータベースの行を受け取り、メールプラットフォーム、広告オーディエンス、CRM に書き込みます。そのコンタクトが無効なら、不正なアドレスが課金対象や送信対象となるシステムに残ってしまいます。書き込みノードの前に VeriMails を呼び出す HTTP Request ノードを置けば、下流のすべてのシステムをクリーンに保てます。
Webhook や
新しいフォーム送信を受け取る Webhook ノードや、データベース・シートのポーリングトリガーといった最もよく使われる n8n のトリガーは、メールデータのソースとしても最もノイズが多いものです。入力ミスや偽のアドレスは絶えず発生します。トリガーの直後に検証ノードを置けば、ワークフローの入り口でそうしたエラーを捕捉できます。
リアルタイム
ワークフロー内で検証すれば、各コンタクトは数週間後の一括エクスポートではなく、Webhook が発火したその瞬間にチェックされます。リストは継続的にクリーンに保たれ、バウンス率が急上昇する余地はなく、最初から誤っていたアドレスにメールを送ることもありません。
不正な
フォームと受信箱の間にいくつノードがあっても、無効なアドレスは最終的にバウンスします。バウンス率が5%を超えると、リスト全体でキャンペーンが迷惑メールに振り分けられやすくなります。ワークフローに VeriMails のノードを入れれば、メールプラットフォームにリスクを負わせるのではなく、発生源でそのリスクを取り除けます。
VeriMailsが
HTTP Request ノードがコンタクトについて VeriMails API を呼び出すと、VeriMails は一連のチェックをすべて実行し、IF や Switch ノードで分岐に使える構造化された結果を返します。すべてのアドレスは次のようにテストされます。
構文検証で、アドレスの形式が正しいかを確認します。 MXとDNSレコードを照会し、ドメインが存在してメールを受信できることを確認します。ライブのSMTPハンドシェイクでは、受信側のメールサーバーに接続し、何も送信せずに、そのメールボックスがメールを受け付けるかを確認します。キャッチオール検出は、送られたすべてのアドレスを受け付けるドメインを特定します。使い捨ての検出は、一時的な受信箱のドメインを検出します。ロールベースの検出は、info@、sales@、support@ のような汎用アドレスを特定します。
VeriMails はわかりやすい検証結果を高速に返すため、Webhook で起動するワークフローにそのまま組み込めます。キャッチオールのドメインは曖昧なスコアではなく明確な検出結果として返されるので、IF ノードのロジックで意図的に扱えます。
n8n ユーザー
リアルタイム検証のワークフローでは、新しいコンタクトが届くたびに VeriMails のクレジットが消費されるため、支払いは検証したアドレス分だけです。クレジットパックは1件あたり$0.0019からで、10,000クレジットは$19です。大量のワークフローや、クライアント向けに n8n を運用する代理店向けには、最大5,000,000件で$1,499までのクレジットパックがあります。
安定したコンタクトの流れに対して予測しやすい請求をご希望なら、年間プランは年払いで月額$12.50からです。新規アカウントには登録時に100クレジットが無料で付与され、クレジットカードは不要、クレジットに有効期限もないため、導入を決める前にワークフローを構築してテストできます。
ワークフローの
このフローで、コンタクトが下流のアプリに届く前に、n8n ワークフローの途中に VeriMails を配置します。
- トリガーの範囲：最初にメールの値を受け取る Webhook、データベース、またはフォームのトリガーの直後に検証します。
- API ステップ： API キーを認証情報として保存し、n8n の式でメールフィールドを渡します。
- 結果への対応： IF または Switch ノードで有効なコンタクトを先へ進め、無効、使い捨て、キャッチオールの結果は別に記録します。
ステップバイステップ
新しい
新しいワークフローを作成し、トリガーノードを追加します。最も一般的なのは Webhook ノードで、コンタクトの作成時やフォームの送信時に外部アプリが呼び出す URL が発行されます。データベースやスプレッドシートのポーリングトリガーも使えます。トリガーは受け取ったペイロードを、下流のノードが読める JSON に解析します。
HTTP Request ノードを
外部 API を呼び出すための n8n の橋渡し役である HTTP Request ノードを追加します。VeriMails の検証エンドポイントにリクエストするよう設定し、式でトリガーノードからメールアドレスを渡し、VeriMails の API キーはノードから参照する n8n の認証情報として保存します。JSON レスポンスは下流のノード向けに解析されます。
IF ノードを
HTTP Request ノードの後に IF ノードを追加します。条件で VeriMails の結果を評価するよう設定し、配信可能なコンタクトは true の分岐へ、配信不可のコンタクトは false の分岐へ進むようにします。使い捨てとキャッチオールの結果も分けたい場合は、3つ以上の出力を持てる Switch ノードを使いましょう。
配信可能な
true の分岐には、コンタクトをメールプラットフォーム、CRM、データベースに書き込むノードを追加します。このノードに届くのは検証済みの配信可能なアドレスだけなので、それらのシステムのリストやオーディエンスは追加のクリーニングなしで自動的にクリーンに保たれます。
不正な
false の分岐には、配信不可や使い捨てのアドレスをデータベースに記録するか、通知を送るノードを追加して傾向を確認できるようにします。サンプルデータでワークフローを実行して各分岐が正しく動くことを確認したら、有効化して、すべての新しいコンタクトを届いた瞬間に検証しましょう。
結果
検証ステータスをワークフローの制御フィールドとして使います。クリーンな n8n ワークフローでは、配信不可の結果を汎用的な false の分岐に埋もれさせず、すべて見える状態にします。
- 配信可能： CRM、データテーブル、メールプラットフォーム、データベースのノードへ進め、可能であれば検証日時を追加します。
- 配信不可：送信ツールや CRM への書き込みノードの前で止め、アイテムをサプレッション用のストアに記録します。
- キャッチオール：大規模なキャンペーンへの登録ではなく、レビュー用の出力か少量の営業向けルートに振り分けます。
- 使い捨て：ナーチャリングのワークフローから外し、必要に応じて、元のフォームに継続して使えるメールアドレスの入力を求める応答を返します。
- ロールベース：共有の受信箱が想定される業務用途には残しますが、個人宛てのシーケンスからは除外します。
- 想定外のステータス：元の JSON、実行 ID、ソースのペイロードを付けて診断用の分岐へ送り、レビューします。