Jotformのメールアドレスを検証する方法

Jotformは、フォームを公開してメールアドレスを集めるのに手軽なツールです。ただし、他のフォームビルダーと同じく、アドレスを集めることは得意でも、そのアドレスが実在するかどうかを見分けることは得意ではありません。メール欄で確認できるのは、アドレスが正しい形式に見えることだけです。メールボックスが存在するか、使い捨てではないか、最初の返信でハードバウンスにならないかは確認できません。このガイドでは、QualisendでJotformのメールアドレスを検証する実用的な方法を2つ紹介します。1つは、送信と同時に動くWebhookを使うリアルタイム検証、もう1つは、送信内容をスプレッドシートにエクスポートして行う一括検証です。どちらもネイティブプラグインは不要です（現時点ではプラグインはありません）。Jotform標準のWebhookまたはエクスポートボタンだけで実現できます。

結論#

検証結果が必要なタイミングに合わせて、方法を選んでください。

• リアルタイム：JotformのWebhookを小さなサーバーレス関数に向けます。送信のたびに、JotformがフォームデータをエンドポイントにPOSTします。関数はメールアドレスを読み取り、Qualisend APIを呼び出し、判定結果に応じて動きます。たとえば、コンタクトにタグを付ける、適切なリストに振り分ける、不正なアドレスにはウェルカムメールの送信を保留する、といった処理です。
• 一括：既存の送信データをCSVまたはExcelにエクスポートし、Qualisendの一括検証にかけます。次回の配信の前に、配信不能なアドレスを除外します。

Jotformのメール欄だけでは不十分な理由#

Jotformのメール項目では、ブラウザー上で形式チェックが行われます。@とドメインがあること、明らかな入力ミスがないことを確認する程度のチェックです。これは正規表現によるチェックと同じ種類のもので、同じ理由で限界があります。 形式が正しいことと到達できることは別です。 jane@gmial.comは形式チェックを通過します。test@mailinator.comも通過しますし、昨年ひそかに運用を終えたドメインの、それらしいアドレスも通過します。

これらは実際に送信するまで見つかりません。送信した時点で、無効なアドレスはハードバウンスとなり、バウンス率と送信者レピュテーションを少しずつ傷つけます。本格的な検証では、Jotformにはできないチェックを追加します。DNS/MXルックアップとSMTPによるメールボックスのプローブに加え、使い捨て、役割アドレス、キャッチオールのフラグも判定します。この仕組みに馴染みがない場合は、 メールアドレス検証で実際に何をチェックするのかが入門として役立ちます。

JotformのメールをQualisendで検証する2つの方法#

まず重要な制約があります。Jotformでは、入力の途中で不正なメールアドレスを確実にブロックすることはできません。すべてのプランで、項目の間に外部APIを呼び出して送信を止める方法は公式にはサポートされていません。そのため、リアルタイム検証は送信の直後にWebhookの中で実行され、入力中のゲートとしては動作しません。この制約は、どちらの方法にも影響します。

方法1：JotformのWebhookでリアルタイム検証する#

Jotformは、すべての送信内容を自分で管理するURLに送れます。フォームを開き、Settings → Integrationsに進み、Webhooksを検索して、エンドポイントのURLを貼り付けます。Webhookを上位プランに限定しているフォームツールもありますが、JotformのWebhooks連携は無料プランを含め幅広く利用できます。プランごとに制限されるのは月間の送信数であり、Webhook自体の利用ではありません。

Jotform特有の癖が、コードの書き方を左右します。JotformはきれいなJSONをPOSTしません。送信内容をフォームエンコードされたフィールドとして送り、各回答には質問に基づいた名前が付きます。メール項目は通常、q3_emailのような名前で届きます。送信内容全体をJSON文字列にしたrawRequestフィールドもあるので、そちらを解析することもできます。どちらの場合も、エンドポイントが読むのはフォームの本文であり、req.json()ではありません。

エンドポイントは、APIキーを保持し、判定結果をアクションに変換するサーバーレス関数です。パターンは サインアップ時の検証ガイドと同じです。キーはサーバー側に置き、結果に応じて処理します。以下はNext.jsのRoute Handlerとして書いた例です （正確なエンドポイントのパスとリクエスト形式は開発者向けドキュメントで確認してください）。

// app/api/jotform-webhook/route.ts
import { NextResponse } from "next/server";

// Single-address check; full reference in /developers.
const QUALISEND_ENDPOINT = "https://app.qualisend.com/api/v1/verify";

export async function POST(req: Request) {
  // Jotform POSTs form-encoded fields, not JSON.
  const form = await req.formData();

  // Jotform names email fields like q3_email — check yours in the builder.
  const email = form.get("q3_email")?.toString();
  if (!email) return NextResponse.json({ ok: true }); // nothing to verify

  const res = await fetch(QUALISEND_ENDPOINT, {
    method: "POST",
    headers: {
      // Store YOUR_API_KEY server-side, never in the browser.
      Authorization: `Bearer ${process.env.QUALISEND_API_KEY!}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ email }),
    signal: AbortSignal.timeout(4000),
  }).catch(() => null); // timeout or network error

  if (!res?.ok) return NextResponse.json({ ok: true, degraded: true }); // fail open
  const { job_id, result } = await res.json();

  // The submission already landed — route on the verdict instead of blocking.
  if (result.status === "undeliverable" || result.sub_flags?.disposable) {
    // Skip the welcome email, tag the contact for review, keep it off the main list.
  } else if (result.smtp === "pending") {
    // Mailbox probe still running: queue job_id and read the final verdict from
    // GET https://app.qualisend.com/api/v1/jobs/{job_id} in a background job.
  }

  return NextResponse.json({ ok: true, status: result.status });
}

この実装を堅牢にするポイントは3つあります。素早く応答する：Jotformは2xxの応答がすぐに返ることを期待しているため、ハンドラーは軽く保ち、すぐに返してください。フェイルオープンにする：APIがタイムアウトしたりエラーを返したりしても、リードを失わないようにします。受け付けたうえで後から再チェックするので、!res?.okの分岐でもok: trueを返しています。そしてエンドポイントを保護する：他のツールのような共有シークレットによるWebhookの署名はJotformにはないため、別の方法でURLを守ります。URLを推測されにくいものにし、検証クレジットを消費する前に、formIDが想定するフォームのものと一致しないリクエストを拒否してください。

タイミングに関する注意点が1つあります。result.smtpが"pending"で返ってきた場合は、メールボックスのプローブがまだ実行中で、最終的な判定結果は少し後にGET /api/v1/jobs/{job_id}で取得できます。取得はハンドラーの中ではなくバックグラウンドジョブで行ってください。そうすれば、Jotformに対して素早く2xxを返せます。

フォームにメール項目が複数ある場合は、最初に見つかったものをそのまま使わないでください。ビルダーが割り当てた具体的なフィールド名（q7_email、q12_workEmailなど）を指定して読み取り、検証するアドレスが常に正しいものになるようにします。各フィールドの名前は、Jotformのビルダーで確認できるほか、テスト送信のペイロードを一度確認すれば分かります。

下流の処理では、判定結果に応じて分岐するだけです。deliverableの結果はそのままCRMやメール配信ツールに渡します。undeliverableやdisposableの結果には、タグを付ける、ウェルカムシーケンスから外す、確認キューに入れるなど、運用に必要な対応を取ります。Webhookはデータを受け渡す仕組みにすぎず、どう振り分けるかは自社で決めます。

検証ロジック自体は言語に依存しません。PythonやPHPを使っている場合は、同じ呼び出しを関数から行えます。同じWebhookの方法は、どのフォームツールにも使えます。ペイロードの解析方法だけが違う、ほぼ同じ構成についてはTypeformのメールを検証する方法をご覧ください。Jotform固有なのはこの解析部分だけで、検証して振り分ける後半はどこでも共通です。

方法2：CSVまたはExcelのエクスポートを一括検証する#

すでに大量の送信データがある場合や、Webhookを組むより定期的にまとめて整理したい場合は、バッチで処理します。JotformでフォームのSubmissionsテーブル（またはReports → Excel/CSV）を開き、データをダウンロードします。1送信が1行になり、メールアドレスは専用の列に入っています。

その後の手順は次のとおりです。

1. ファイルをアップロードして、Qualisendの一括検証にかけます。MX、SMTP、使い捨て、役割アドレス、キャッチオールのフラグを含む全工程が、すべての行に対して実行されます。
2. 注釈付きのファイルをダウンロードします。各アドレスに、status、reasonコード、0～100のscoreが付いて返ってきます。
3. 実際に配信に使っているツールで配信不能なアドレスを除外し、リスクのある行は慎重に扱います。各ステータスをどこに振り分けるかを含む一連の手順は、 メールリストをクリーニングする方法で解説しています。

一括検証は溜まったデータの処理には最適ですが、予防ではなく事後の整理です。ここで見つかるアドレスは、すでにリストに載っていたものがほとんどです。定期的な一括検証とリアルタイムのWebhookを組み合わせ、新しい不正なアドレスを到着した時点で検知しましょう。

判定結果に応じた対応#

どちらの方法で結果を受け取っても、構成は同じで、status、reason、score、sub_flagsが返ります。それぞれを次のアクションに対応させます。

セットアップの準備はできましたか。スコープ付きのキーと正確なリクエスト形式は開発者向けドキュメントで確認できます。1件のアドレスを試しに確認するには、無料メールチェッカーで行えます。すべてのプランに含まれる無料の100クレジットを使えば、最初から最後までフローを試せます。