Webflowフォームのメールアドレスをバウンス前に検証する方法

Webflowはすべてのサイトにフォームを用意していますが、asdf@asdf、使い捨てのアドレス、@gmial.comのような入力ミスも、本物のリードと並べてそのまま保存してしまいます。こうしたアドレスは、ESPがメールを送った時点でどれもハードバウンスになります。Webflowフォームのメールアドレスを検証するには、送信内容をCRMに登録する前に検証チェックへ回します。送信の瞬間にリアルタイムで検証する方法と、後からまとめて検証する方法があります。このガイドでは両方を取り上げ、リアルタイム方式の動くコードを示すとともに、Webflowのプランによる制約についても正直にお伝えします。

結論#

現在、WebflowにインストールできるQualisendアプリはありません（ネイティブのプラットフォーム連携は作り直し中です）。そのため、どちらの方法もアプリを介さずに実現します。リアルタイム： 各送信内容を小さなサーバー側関数に渡します（Webflowのフォームウェブフック経由、またはMake/Zapierの「watch form submissions」ステップ経由）。この関数が検証APIを呼び出し、判定結果に応じて処理してから、リードを下流に同期します。一括： Webflowのフォーム送信内容をCSVにエクスポートし、一括検証ジョブにかけます。リアルタイムなら不良アドレスをリストに入れずに済み、一括なら既にあるリストをクリーニングできます。

Webflowフォームのメールアドレスを取得時点で検証する理由#

Webflowフォームの段階で無効なアドレスを見つければ、バウンスは発生しません。同じアドレスに3回送信した後で見つけた場合、配信の試行にコストがかかり、バウンス率を押し上げ、送信者レピュテーションにも悪影響を与えています。取得時の検証は予防であり、リストのクリーニングは事後対応です。予防のほうが、あらゆる面で低コストです。バウンスはしないものの被害をもたらす、目立たない問題も防げます。たとえばinfo@のように特定の誰も読んでいない役割アドレスや、一度も開封されないまま購読者数と料金だけを膨らませる使い捨てアドレスです。

構文チェック、MX、SMTPメールボックスプローブといった仕組みを知りたい場合は、メールアドレス検証の仕組みで、各判定が出るまでのパイプラインを解説しています。

パターン1：ウェブフックによるリアルタイム検証#

リアルタイム検証とは、Webflowでの送信から、ESPやCRMへの同期までの間にチェックを実行する方式です。次の3つの要素で構成します。

1. Webflowから送信内容を取り出す。 Webflowは、フォームの送信内容をすべて、自分で用意したURLにPOSTできます。有料のSiteプランでは、form_submissionウェブフックを登録できます（Site settings → Integrations、またはWebflowのData API経由）。これは、Webflowが保存する送信内容に影響を与えずに動作します。ノーコードの代替手段として、MakeまたはZapierを接続し、Webflow用の「new form submission」トリガーを使い、関数へPOSTするWebhooksステップを追加する方法もあります。いずれの場合も、送信先は自分で管理する小さなエンドポイントにします。検証APIを直接指定することは絶対に避けてください。APIキーを置きたくない場所に置くことになるためです。
2. サーバー側関数。 APIキーを保持し、検証エンドポイントを呼び出して、レスポンスをもとに対応を判断します。
3. 同期ロジック。 判定結果が問題ない場合にのみ、リードをCRMへ送ります。

検証関数#

ここでは、中間にあたる処理をサーバーレス関数として示します。この形はVercel、Netlify、Cloudflare Workers、そのほかHTTPハンドラーを使えるホストで動作します。この関数は、ウェブフックのペイロードからメールアドレスを取り出し、APIを呼び出して、対応を判断します。以下のエンドポイントのパスとペイロードはプレースホルダーです。正確なリクエストはAPIリファレンスで確認してください。スコープを限定したキー（YOUR_API_KEY）は環境変数に入れてサーバー側だけに置き、Webflowのページコードには絶対に含めないでください。

// api/webflow-verify.js — Webflow (or Make/Zapier) POSTs form submissions here
export default async function handler(req, res) {
  // Webflow's form_submission webhook nests the fields under `data`;
  // a Make/Zapier Webhooks step can forward the same shape.
  const fields = req.body?.data ?? req.body ?? {};
  const email = fields.email ?? fields.Email;
  if (!email) return res.status(400).json({ error: "no email field" });

  let verdict = { status: "unknown" }; // default if the API can't be reached
  try {
    const r = await fetch("https://app.qualisend.com/api/v1/verify", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.QUALISEND_API_KEY}`, // your scoped key
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(4000), // don't let a slow probe stall the webhook
    });
    if (r.ok) {
      const { job_id, result } = await r.json();
      verdict = { ...result, job_id }; // { status, reason, score, sub_flags, smtp, job_id }
    }
  } catch {
    // timeout or network error — fall through as "unknown" and sync anyway
  }

  // Act on the verdict BEFORE the lead reaches your ESP/CRM.
  if (verdict.status === "undeliverable" || verdict.sub_flags?.disposable) {
    return res.status(200).json({ synced: false, status: verdict.status });
  }

  await syncToCrm(email, fields, verdict); // your existing ESP/CRM call
  // smtp "pending": the mailbox probe is still running. A background job (not this
  // handler) polls GET /api/v1/jobs/{job_id} for the final verdict and updates the lead.
  if (verdict.smtp === "pending") await queueVerdictCheck(verdict.job_id, email);
  return res.status(200).json({ synced: true, status: verdict.status });
}

レスポンスには、status（deliverable、risky、undeliverable、unknown）、reasonコード、0～100のscore、そしてdisposable、role、free_mail、catch_allを示すsub_flagsが含まれます。リードを振り分けるのに必要な情報はこれですべてです。最初の判定はすぐに返ります。smtpフィールドが"pending"の場合は、メールボックスプローブがまだ実行中です。この場合、スニペットはjob_idをバックグラウンドジョブに渡します。バックグラウンドジョブはGET /jobs/{job_id}から最終判定を読み取ってリードを更新します。こうすれば、ウェブフックを開いたままにしたり、/verifyを再度呼び出したりせずに済みます。 サーバーレスでの実装上のポイントは、キーの保持、タイムアウト、そしてフェイルオープンです。これらはサーバーレス関数でサインアップ時にメールアドレスを検証する方法で詳しく解説しています。APIの呼び出しをNode向けに示したものは、Node.jsでメールアドレスを検証する方法にあります。

判定結果に応じた対応#

同期の前に検証を行う目的は、すべてを通過させるのではなく、振り分けを判断できるようにすることです。

Webflowのプランによる違い#

実際にどの仕組みを使えるかはプランによって異なるため、事前に確認しておいてください。

• ネイティブのform_submissionウェブフックとサイトへのカスタムコードの追加には、有料のWebflow Siteプランが必要です。無料プランではウェブフックもカスタム埋め込みも使えず、フォームの送信件数にも上限があります。
• フォームアクションの上書き（フォームのaction URLを自分のエンドポイントに直接向ける方法）は、ウェブフックなしで動作します。ただし、Webflow自身の送信内容の保存とメール通知をバイパスするため、送信処理をすべて自分で引き受けることになります。
• MakeまたはZapierを使うと、Webflow側のプランの問題は回避できますが、それらのサービス側で料金がかかるステップが増え、遅延も加わります。多くのチームにとっては、有料プランに移行した後であればネイティブのウェブフックが最もシンプルなリアルタイムの方法です。

迷ったら、すでに利用できるものから始めてください。中間にある関数は、送信内容がどのように届いたかを問いません。

パターン2：エクスポートした送信内容を一括検証する#

リアルタイム検証が今は手間に感じる場合や、これらを設定する前に集めた送信内容がすでにたくさんある場合は、代わりに一括で検証します。

1. Webflowのサイト設定にある Forms パネルを開き、送信内容をCSVにエクスポートします（送信内容のエクスポートは有料プランの機能です）。
2. そのCSVをQualisendの一括検証ジョブにアップロードします。各行に、リアルタイムAPIと同じstatus、reason、score、sub_flagsが返ります。
3. deliverableの行は残し、undeliverableとdisposableは削除または隔離します。riskyとcatch_allは、ケースごとに判断します。
4. クリーニング済みのリストをESPにインポートします。

これは通常のリスト衛生管理のサイクルです。フラグの読み方や、各区分への対処は、メールリストのクリーニング方法で解説しています。Webflowがこれまでに集めたすべてのデータを一度だけ監査する場合も、一括検証が最適です。無効と分かっているアドレスをCRMに残しておく理由はありません。

どちらの方法を選ぶべきか#

多くのチームは両方を併用しています。リアルタイムで今後のリストをクリーンに保ち、ときどき一括で検証して、登録後に無効になったアドレスを見つけます。

Webflowのネイティブアプリはありますか？#

現時点ではありません。Qualisendのネイティブなプラットフォーム連携は作り直し中のため、WebflowのマーケットプレイスでQualisendのアプリ、プラグイン、コネクターを探しても見つかりません。Webflowのネイティブ連携は、現在提供されているのではなく、ロードマップに入っている段階です。連携が提供されるまでは、ウェブフックと関数を組み合わせた上記の方法がサポート対象のリアルタイム方式であり、それ以外はCSVの一括検証でカバーできます。どちらも、ネイティブ連携の提供を待つ必要はありません。

Webflowのリードから不良アドレスを排除する準備はできましたか？まずは1件ずつチェックできるツールで任意のアドレスを無料で試してください。/verifyエンドポイントとスコープ付きキーはAPIリファレンスから入手できます。無料プランの100クレジットで、ウェブフックの動作をエンドツーエンドで確認できます。