Formstackのメールを検証する方法

Formstackは、登録受付、リード獲得フォーム、サポートの受付、イベント申し込みなど、データを集めるために作られたツールで、その役割を十分に果たします。ただし、入力されたメールアドレスが、実在して到達できるメールボックスかどうかまではわかりません。さらに、Formstackの送信内容は変更できません。回答が登録された時点で、そのレコードは固定されたスナップショットになります。中にある不正なアドレスを、後から「修正」することはできないのです。したがって、検証が実際に効果を発揮するのは、データを取得する時点、つまりアドレスがFormstackを出てCRMやメールツールに向かう瞬間だけです。このガイドでは、Qualisendを使ってFormstackのメールを検証する方法を説明します。送信が届くたびにリアルタイムで検証する方法と、既存の回答をCSVにエクスポートして一括で検証する方法です。

Formstackのフォーム検証が不正なメールを通してしまう理由#

FormstackのEmailフィールドは、フロントエンドで検証を行います。値に@とドメインがあり、明らかに不正な文字がないかを確認し、「confirm email」フィールドを追加して回答者に2回入力させることもできます。これで、フィールドが明らかに中途半端なまま送信された入力ミスは防げます。しかし、メールボックスが実在することの証明にはなりません。

形式の検証は、正規表現と同じ種類のチェックであり、失敗する理由も同じです。形式が正しいことと、メールが届くことは別です。jane@gmial.comは問題なく通過します。形式は完全に正しく、ただ存在しないドメイン宛てになっているだけです。1時間以内に使えなくなる使い捨てアドレスのsignup@mailinator.comも通過します。昨年閉鎖した会社のドメインにある、本物らしく見えるアドレスも通過します。Formstackの標準チェックには、DNSを解決する、MXレコードを調べる、メールボックスに問い合わせて誰かいるか確かめる、といった機能はありません。

こうした不正なアドレスは、実際に送信するまで見つかりません。その時点では、宛先が無効なためにハードバウンスとなり、バウンス率と送信者レピュテーションを少しずつ損ないます。本格的な検証は、Formstackのフィールドにはない層を加えます。DNS/MXの検索、SMTPによるメールボックスのプローブ、使い捨て・役割アドレス・キャッチオール・メールボックス容量超過のフラグです。この仕組みに馴染みがなければ、メールアドレス検証が実際に確認することが入門として役立ちます。

データ取得の時点で検証する#

Formstackの送信内容は後から編集できないため、検証の価値が最も高いのは、アドレスがフォームから流れ出る瞬間です。リスト、CRM、ウェルカムメールに届く前に検証すれば、入力ミスや使い捨てアドレスにフラグやタグを付けたり、確認用に振り分けたりでき、気づかないうちに購読者になることを防げます。

Formstackは、新しい送信を受け取ると同時に外部へ送り出します。この送り出す経路が、チェックを差し込む場所です。接続方法は2つあります。

• ノーコード（ZapierまたはMake）：Formstackはどちらにも接続できます。「New Submission」トリガーが回答ごとに起動します。送信されたメールアドレスを使ってQualisendを呼び出すステップを追加し、判定に応じて分岐させます。deliverableのアドレスはCRMやメールプラットフォームに送り、それ以外は保留、タグ付け、別ルートへの振り分けを行います。このパターンの詳しい手順はZapierでメールを検証する方法にあり、Formstackのトリガーにそのまま対応します。
• 直接（ウェブフック）：Formstackは、各送信のデータを、自分で管理しているURLにPOSTできます。メールフィールドを読み取り、サーバー側のスコープ付きキーでQualisendの検証APIを呼び出し、結果に応じて処理する小さなサーバーレス関数に向けてください。これは登録時の検証で説明しているサーバー側のパターンと同じです。キーがブラウザに渡ることはなく、判定に応じて処理を分岐させます。

どちらの方法を選ぶ場合も、重要な点を正直にお伝えします。判定をFormstackの送信内容に書き戻すことはしません。そのレコードは、取得した時点のまま残ります。行うのは、アドレスが移動する途中での検証と、その結果を受けて下流のシステムがどう動くかの判断です。deliverableの結果はそのままリストに流れます。undeliverableやdisposableのアドレスは、送信に悪影響を与える前に、抑制、タグ付け、確認用キューへの振り分けのいずれかを行います。

チェックのたびに、deliverable、risky、undeliverable、unknownのいずれかの判定が返ります。それぞれに、理由コード、キャッチオール・使い捨て・役割アドレス・メールボックス容量超過のサブフラグ、MXプロバイダー、SMTPプローブの証拠、0～100の信頼スコアが付きます。undeliverableは抑制、riskyやキャッチオールは慎重に送信するセグメントに振り分けます（キャッチオールドメインでは個別のメールボックスを確認できません）。unknownを理由に、本物のリードを捨ててはいけません。unknownは、先方のインフラが応答しなかったという意味です。いったん受け入れて、後で再チェックしてください。役割アドレスと使い捨てのフラグを使えば、ファネルをどこまで厳しくするかを決められます。それぞれの扱いは役割アドレス、使い捨てアドレス、フリーメールアドレスをご覧ください。

Formstack向けのQualisendネイティブコネクターは準備中で、進捗はFormstack連携ページで確認できますが、まだ提供されていません。現在サポートしているのは、上記のZapier/Makeのフローと、APIを直接呼び出すウェブフックの2つです。どちらもFormstackの標準機能を使うため、待つ必要はありません。

過去の送信をクリーニングする#

リアルタイム検証が守るのは、今日以降のデータすべてです。すでにアカウントにあるアドレスには効果がありません。それらは、一括処理で一度に対処します。

FormstackでフォームのSubmissionsビューを開き、回答をCSVまたはExcelにエクスポートします。送信ごとに1行となり、メールアドレスは専用の列に入ります。続いて、次の手順で進めます。

1. CSVをアップロードする。Qualisendの一括検証にアップロードします。1つのジョブで最大1,000,000件のアドレスを処理でき、重複は1回分しか課金されないため、同じ人が繰り返し送信している雑多なエクスポートでも、余分な費用はかかりません。Qualisendは、MX、SMTPプローブ、使い捨て・役割アドレス・キャッチオール・メールボックス容量超過のフラグという一連の処理を、すべての行に対して実行します。
2. 注釈付きのファイルをダウンロードする。各アドレスに、判定、理由コード、サブフラグ、0～100のスコアが付いて返されます。
3. undeliverableを抑制する。実際にメールを送信しているツールで抑制し、riskyの行は慎重に扱います。Formstackのエクスポートは元データです。クリーニングしたリストは、送信元のツールに置きます。

一括処理は、たまった分を片づけるのに適したツールですが、予防ではなくクリーンアップです。ここで見つかるアドレスは、すでにしばらくCRMに残っていたものがほとんどです。定期的な一括処理と、データ取得時のリアルタイムチェックを組み合わせれば、過去のデータも新しい登録もクリーンに保てます。上記のFormstackの動作は、2026年8月時点のFormstackのドキュメントで確認したものです。