n8nでメールアドレスを検証する方法

専用ノードの登場を待たなくても、n8nで今日からメールアドレスを検証できます。n8nの汎用HTTP RequestノードでQualisend APIを問題なく呼び出せますし、n8nはオープンソースでセルフホストも可能なので、フロー全体を自分で管理するインフラ上で動かし、APIキーもn8n自身の認証情報の保管庫に保存できます。構成は常に同じ3つのノードが中心です。トリガーがアドレスを受け取り、HTTP RequestノードがQualisendにPOSTし、IFまたはSwitchノードが返されたstatusを読み取って結果ごとに振り分けます。メールボックスのチェックがまだpendingの間は、後ろの2つのノードの間に短いWaitとGETのループを挟んで、最終的な判定結果を取得します。このガイドでは、このワークフローを最初から最後まで構築します。

結論から#

n8nにQualisendのネイティブノードはまだありません（ロードマップには入っています）。そのため、対応している方法は汎用ノードで組むワークフローです。構成は次のとおりです。

• トリガー（Webhook、フォーム、新しい行、スケジュール）
• 保存済みの認証情報に入れたキーを使い、メールアドレスを検証APIにPOSTするHTTP Requestノード
• result.statusで分岐するIFまたはSwitchノード

最初のレスポンスでresult.smtpがpendingの場合はメールボックスのチェックがまだ実行中なので、分岐の前に短いWaitとGETのループで最終的な判定結果を取得します。キーはn8nの認証情報に保管し、ノードに直接貼り付けたり、公開フィールドに置いたりしないでください。また、HTTP呼び出しがエラーになった場合は、アドレスを通過させる設定にしておきます。一時的な不具合で本物の登録を気づかないうちに失わないためです。

n8nでメールアドレスを検証する2つの方法#

設定を始める前に、データにどの程度の鮮度が必要かに合わせて方式を選びます。

1. リアルタイム、レコードごとに検証（稼働中のワークフロー）。新しいアドレスが届いた時点で検証し、その場で振り分けます。このガイドの中心となる方法で、判定結果によって次の動きが変わる場合に向いています。たとえば、ウェルカムメールを送るかどうかの判断、リードへのタグ付け、偽の登録の除外などです。
2. バッチ、後からまとめて検証（CSV）。レコードをシート、データベース、CRMに溜めておき、定期的にエクスポートして一括検証ジョブにかけます。手順が簡単でアドレス単価も抑えられ、即時の判断は不要で送信前にリストをきれいにしたい場合に適しています。

多くのチームは両方を併用しています。入口には稼働中のワークフローを置き、登録後に古くなったアドレスを拾うため、定期的にリストのクリーニングを行う構成です。検証パイプラインそのものに馴染みがない場合は、メールアドレス検証の仕組みで、1回のリクエストの裏でAPIが実際に何をしているかを説明しています。

ステップ1：トリガーノード#

アドレスを受け取るものをワークフローの起点にします。n8nには多くの選択肢があり、どれも同じ後続ノードにつながります。

• フォームやアプリが、自分で管理するURLに送信内容をPOSTする場合はWebhookノード。
• n8n自身に入力フォームをホストさせたい場合はn8n Form Triggerノード。
• 新しい送信や新しい行で起動する、Typeform、Google Sheets、Airtable、HubSpotなどのアプリトリガー。
• タイマーで少しずつまとめてレコードを確認したい場合は、データベースやスプレッドシートの読み取りにつなぐSchedule Triggerノード。

トリガーが特定のフォームツールの場合は、プラットフォーム別の手順であるTypeformからメールアドレスを検証する方法から、以降のHTTP RequestとIF/Switchのステップに引き継げます。変わるのはトリガーノードだけです。

どれを選ぶ場合も、重要なのはメールアドレスがアイテムのJSONに入り、後続のノードから参照できることです。一般的には{{ $json.email }}のように参照します（キーはトリガーの出力に合わせて調整してください。Webhookのペイロードでは{{ $json.body.email }}、フォームノードでは設定したフィールドラベルの名前で参照できる場合があります）。次のノードを作る前に、トリガーでExecute stepボタンを使って正確なパスを確認してください。

ステップ2：HTTP RequestノードでQualisend APIを呼び出す#

トリガーの後にHTTP Requestノードを追加します。このノードが実際にQualisendを呼び出します。次のように設定してください。

トリガーのアドレスがそのまま渡るように、JSONボディは式で設定します。

{ "email": "{{ $json.email }}" }

n8nが代わりに送信するリクエストは、次のようになります。プレースホルダーは、開発者向けドキュメントを見て埋めてください。ドキュメントには正確なエンドポイントと、複数の言語によるリクエスト例が載っています。

POST https://app.qualisend.com/api/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

キーは、フルアクセスのキーではなく、検証のみに限定したスコープ付きの認証情報として作成してください。ワークフローのJSONやログから参照先が漏れても、それが指すキーでできるのは検証だけで、それ以外には触れられません。n8nでは、このキーをHeader Auth認証情報に入れます。n8nは認証情報をワークフローとは別に保存し、保存時に暗号化します（セルフホスト環境ではN8N_ENCRYPTION_KEYで暗号化されます）。そのため、シークレットがノードのパラメーター、エクスポートしたワークフロー、実行ログに現れることはありません。

Execute stepでノードを実行すると、n8nがレスポンスボディを表示します。resultの中には、status、reasonコード、0～100のscore、sub_flagsのセット、メールボックスのチェックが完了したかを示すsmtpフィールドが入っています。有効なドメインの新しいアドレスは、通常次のような内容が返ります。

{
  "job_id": "3f2b6c1e-8a4d-4f7e-9c21-5b0d7e9a1c44",
  "result": {
    "status": "unknown",
    "reason": null,
    "score": 60,
    "smtp": "pending",
    "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
  }
}

このunknownはまだ判定結果ではありません。レスポンスは、高速なローカルチェック（構文、ドメインとMX、使い捨て、役割アドレス、入力ミス）が終わった時点で返りますが、SMTPによるメールボックスのチェックはまだ実行中です。最終的な判定結果はステップ3で取得します。smtpがcachedまたはskippedの場合は、resultがすでに最終結果です。

次のノードではこれらのフィールド名で分岐します。ステータスは{{ $json.result.status }}、サブフラグは{{ $json.result.sub_flags.disposable }}で参照できます。同じサーバー側のリクエストの構成は、サーバーレスでのサインアップ検証ガイドの土台にもなっています。違いは、自分でデプロイする関数の代わりに、n8nが呼び出しを担う点だけです。

ステップ3：メールボックスのチェックがpendingの場合に最終的な判定結果を取得する#

pendingのレスポンスのまま分岐すると、実際の登録の大半がunknownの経路に流れてしまいます。そこで、HTTP Requestノードとルーターの間に、最初の呼び出しで作成されたジョブを読み取る短いポーリングのループを追加します。

1. IFノード：{{ $json.result.smtp }}がis equal to pending。falseの出力（cachedまたはskipped）はすでに最終結果なので、そのままステップ4に進みます。
2. trueの出力には、5～10秒に設定したWaitノードを置きます。
3. 2つ目のHTTP Requestノードを、メソッドGET、同じHeader Auth認証情報、次のURLで設定します（Verify emailは、最初のHTTP Requestノードにつけた名前に置き換えてください）。 https://app.qualisend.com/api/v1/jobs/{{ $('Verify email').item.json.job_id }}?include=results
4. ジョブが完了したかを調べるIFノード：{{ $json.status }}がcompleted、failed、canceledのいずれかと等しい（3つの条件をORで組み合わせます）。そのfalseの出力は、Waitノードに戻します。
5. trueの出力にはEdit Fields (Set) ノードを置き、resultという名前のフィールド（型はObject）に{{ $json.results[0] }}を設定します。これで、どちらの経路もステップ4に同じresult.statusとresult.sub_flagsを渡せます。

ポーリングの1回ごとの呼び出しは通常のAPI呼び出しです。クレジットは消費しませんが、ワークスペースの1分あたりのレート制限には含まれるため、待機時間は5～10秒で十分です。アドレスを「更新」する目的で検証エンドポイントを再度呼び出さないでください。2クレジット目を消費します。failedまたはcanceledで終わったジョブには判定結果が含まれないため、unknownとして扱います。また、送信が届いたらすぐにトリガーが応答するようにしてください（WebhookノードのデフォルトのRespond: Immediately）。登録する人がこのループを待たされることはありません。

ステップ4：IFまたはSwitchで判定結果ごとに分岐する#

検証結果を活用しなければ、クレジットが無駄になります。アドレスごとに処理を変えることが目的で、n8nにはそのためのノードが2つあります。

オプションA：IFノード（最も簡単）。「良いアドレスだけを残したい」場合は、ステップ3の2つの経路が合流する位置にIFノードを追加します。条件は次の1つを設定します。

• Value 1： {{ $json.result.status }}、String、is equal to、Value 2： deliverable

条件に一致したものはtrueの出力から後続のノードに進みます（ESPへの追加、コンタクトの作成、ウェルカムメールの送信など）。それ以外はfalseの出力に出るので、破棄するか保留にします。シンプルですが大雑把でもあり、risky、unknown、undeliverableをまとめて同じ扱いにします。実際には、これらを別々に扱いたい場合が多いでしょう。

オプションB：Switchノード（結果ごとに振り分け）。 RulesモードのSwitchノードを使うと、ステータスごとに別々のブランチへ分けられます。各ブランチには専用の後続ノードを置けます。

サブフラグでも分岐できます。レピュテーションを重視するプロダクトでは、{{ $json.result.sub_flags.disposable }}がtrueのアドレスを、ステータスに問題がなくても確認用のブランチに回すルールを追加してください。使い捨てアドレス、役割アドレス、フリーメールアドレスの扱いについては、役割アドレス・使い捨て・フリーメールの違いで解説している判断と同じ考え方です。Switchのルールは上から順に評価されるため、最も厳しいブランチを先頭に置き、どれにも一致しないものにはfallbackの出力をつなぎます。

API呼び出しが優良なリードを落とさないようにする#

何よりも大事なルールは、フェイルオープンにすることです。HTTP Requestノードがエラーになったとき（APIが一時的に遅い、プランの上限に達した、ネットワークが一瞬不安定になったなど）に、実行全体が止まって本物の登録を気づかないうちに失う事態は避けなければなりません。HTTP RequestノードのSettingsタブを開いてOn ErrorをContinue (using error output) に設定し、判定結果のないアドレスはunknownとして扱います。破棄せずに保管し、確認用に回して、後で再チェックします。ステップ3のGETノードにも同じ設定をしてください。

検証APIは品質を確かめるフィルターであり、認証のゲートではありません。一時的な障害のために料金を支払っている顧客を弾くより、疑わしいアドレスを1件通してしまい、次回のリストのクリーニングで見つけるほうが、はるかに被害は小さくなります。セルフホストしている場合は、ノードに妥当なタイムアウト（数秒）と、1～2回のリトライを設定しておくのも有効です。1回の遅いプローブで、混み合ったワークフローのキューが止まるのを防げます。

代替案：CSVエクスポートを一括検証する#

n8nは連携のためのつなぎ役ですが、それなりのコストがかかります。検証するアドレスごとに1回の実行が発生するため、レコードごとのHTTP呼び出しは、即時の判断が不要な場合には過剰に感じられたり、積み上がったりします。次のような場合は、バッチ方式を選んでください。

• すでにあるリストをクリーニングする場合。新規の流入ではなく、過去の数千件のコンタクトが対象です。エクスポートして、一括ジョブを1回実行します。
• ボリュームが多く、実行ごとのオーバーヘッドの負担が大きい一方で、毎晩または毎週のクリーニングでもデータの鮮度が足りる場合。
• 1回限りのクリーニングのために、常時稼働するワークフローを維持したくない場合。

この3つのケースではワークフローを使わず、データベース、シート、CRMからレコードをCSVにエクスポートし、そのファイルをQualisendの一括検証にアップロードします。行ごとに同じstatus、score、サブフラグが得られ、クリーニング済みのファイルとしてダウンロードして再インポートできます。自動化を保守せずに、リストを健全に保ち、バウンス率を低く抑えられる、最も手間の少ない方法です。このエクスポートと検証自体を、独立したスケジュール実行のn8nワークフローにすることもできます。

n8nのHTTPノードを使う方法と、自社のバックエンドからAPIを直接呼び出す方法のどちらにするか迷う場合は、APIの比較に両者のトレードオフをまとめています。n8nは設定の速さとビジュアルなルーティングで勝り、直接連携は規模が大きいときのコストと制御の面で勝ります。セルフホストしたくない場合は、同じ3ステップの構成をZapierでも実現できます。

構築の準備はできましたか。スコープ付きキーと正確なリクエスト形式は開発者向けドキュメントで入手できます。アドレスの簡単な確認には無料メールチェッカーが使えます。そして無料プランから始めましょう。100クレジットあれば、ワークフロー全体を構築し、不正なアドレスがリストに届く前に除外される様子を確認できます。