Tallyの送信内容からメールアドレスを検証する方法

Tallyはフォームをすばやく作成して回答を集め始められるため、リード、サインアップ、アンケートの連絡先の収集に使っているチームが数多くあります。しかし、そのメールアドレスに実際にメールを送ろうとして初めて表面化する問題があります。Tallyが受け付けた送信内容は、実際に機能するメールアドレスとは限りません。さらに、Tallyの回答は変更できません。送信ボタンが押された時点で、その行は固定されます。そのため、最も効果が大きいのは、アドレスを取得する時点での対策です。このガイドでは、Tallyから届くメールアドレスを検証する方法、フォーム標準の検証では不十分な理由、すでに集めた回答をクリーニングする方法を説明します。

Tallyのフォーム検証が不正なメールアドレスを通してしまう理由#

Tallyでは、メール欄を必須にして入力タイプをメールに設定でき、ブラウザーはアドレスの形をしていない入力を受け付けません。これは役に立ちますが、チェックされるのは形式だけです。形式の検証で分かるのは、name@domain.comがメールアドレスの形をしていることだけです。そのメールボックスが存在するか、ドメインがメールを受信できるか、本人がアドレスを正しく入力したかは分かりません。

実際には、フロントエンドの検証は、次のような問題のあるアドレスを素通りさせます。

• 実在しそうなドメインでの入力ミス。user@gmial.comやuser@yaho.comは、あらゆる形式チェックを通過します。構文は完璧でも、配信はまったくできません。
• 使い捨てのアドレス。リードマグネットを入手する人は、使い捨てのメールアドレスを使いがちです。形式は有効でも、そのアドレスは10分で自動的に消えます。
• 役割アドレス。info@、support@、admin@は形式こそ正しいものの、共有の受信トレイに届いたり、マーケティングメールを送ると迷惑メールフィルターに引っかかったりすることがよくあります。
• 使えなくなったメールボックス。かつて機能していたドメインが使われなくなったり、特定のメールボックスが満杯になったり無効化されたりすることがあります。フォームにはそれを知る手段がありません。

パターンマッチングでこれらを見つけられない仕組みを詳しく知りたい場合は、正規表現による検証が失敗する理由にまとめています。要点は、形式が正しいことは必要条件ではあっても、十分条件にはまったく及ばないということです。これらのアドレスはどれも、正常なアドレスとまったく同じ見た目で回答テーブルに入ります。さらにTallyの回答は後から編集できないため、その場で直すことはできません。対策は、値を信頼する前に行うか、別途クリーニングの工程を設けて行う必要があります。この分野が初めての場合は、メールアドレス検証とはで、実際の到達率チェックが何を行うのかを説明しています。

アドレスを取得する時点で検証する#

最も確実な方法は、アドレスが届いた瞬間にすべて検証し、CRMやメール配信ツール、アウトバウンドのシーケンスに到達する前にチェックすることです。Tallyは新しい送信ごとにWebhookを実行でき、この送信イベントが検証のきっかけになります。

最も手早い方法は、QualisendのネイティブなTally連携です。Tally連携のページから一度接続すると、Qualisendが新しい送信をリアルタイムで検証し、リストをその場でクリーニングします。判定結果は1件ずつ書き戻されるので、エクスポートしなくても、リストは常に信頼できる状態に保たれます。既存の連絡先も、1回の処理でまとめて扱えます。プランを問わず自分で構築したい場合や、すでに自動化を組んでいる場合は、以下のWebhookを使う方法がどこでも使えます。

ノーコードで構築する場合は、Tallyの送信内容をZapierまたはMakeに渡します。どちらでも流れは同じです。「New Tally Submission」トリガー、メール欄を受け取るQualisendの検証ステップ、結果に応じて動くフィルターまたはルーターの順に組みます。deliverableはそのままリストに送り、riskyとunknownは確認のために保留し、undeliverableは下流のデータを汚す前に破棄します。n8nを使っている場合も、Qualisendで対応できます。

Webhookを受け取る自前のエンドポイントからサービスを直接呼び出したい場合は、Verification APIが1件のアドレスを受け取り、1回のリクエストで構造化された判定結果を返します。結果は、deliverable、risky、undeliverable、unknownの4つのいずれかで、それぞれに理由コードが付きます。さらに、キャッチオール、使い捨て、役割アドレス、メールボックス満杯のサブフラグ、MXプロバイダー、SMTPプローブの証跡、0～100の信頼スコアも返ります。人手を介さずに、保持、保留、破棄を自動で判断するのに十分な情報です。このチェックをインラインで実行する方法全般はサインアップ時のメール検証で解説しており、フォームのWebhookにそのまま当てはめられます。

取得時に検証すれば、入力ミスや使い捨てのアドレスがそもそもリストに入りません。Tallyの回答は送信後に編集できないため、境界で問題を止めるほうが、後から整合性を取ろうとするよりずっときれいです。

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

Tallyでしばらく回答を集めてきた場合は、処理すべき回答がすでに溜まっています。ここでは回答が変更できないことが、かえって有利に働きます。作業中にデータが変わることがないため、1回限りのクリーニングを簡単に行えます。

1. 回答をエクスポートします。TallyでフォームのSubmissionsビューを開き、回答をCSVとしてエクスポートします。このファイルには、メールアドレスの列を含むすべての送信内容が入っています。
2. ファイルを1回の処理で検証します。CSVをQualisendに一括ジョブとしてアップロードします。1つのジョブで最大1,000,000件のアドレスを処理でき、重複は1回分だけが課金されるため、同じ人が何度も送信していても追加の費用はかかりません。各行には、APIと同じ4つの判定、理由コード、サブフラグ、MXプロバイダー、SMTPの証跡、信頼スコアが返ります。
3. 判定結果に応じて対応します。deliverableの行は残し、riskyとunknownは自社のリスク許容度に照らして確認し、undeliverableは除外します。キャッチオールのドメインは別にフラグが付くので、どこまで厳しく扱うかを判断できます。扱い方はキャッチオールアドレスとはをご覧ください。そのうえで、クリーニング済みのセグメントを、実際に送信に使っているツールにインポートします。

Tallyの回答は読み取り専用のため、結果をTally自体に書き戻すことはありません。エクスポートして検証し、クリーンなリストをメールプラットフォームやCRMに読み込みます。ネイティブ連携では、このデータの書き戻しをQualisend側で処理して検証済みのリストを同期しますが、送信の基準となるデータの置き場所は、フォームではなくマーケティングツールにしてください。

これを正しく行えば、守れるのは1回のキャンペーンだけではありません。メールプロバイダーは、存在しないアドレスにどれだけ送信したかを見ており、配信不能なアドレスだらけのリストはバウンスを増やし、受信トレイへの到達率を押し下げます。全体像については、メール到達率ガイドとバウンス率が重要な理由で、クリーンなリストが送信者レピュテーションを守る仕組みを説明しています。また、GoogleとYahooの送信者ガイドラインの遵守にもつながります。現在は、汚れたTallyのエクスポートをそのまま使うと簡単に超えてしまうバウンスのしきい値が適用されています。

どの方法を選ぶ場合でも、まずは無料プランから始めてください。1回限り付与される、有効期限のない100クレジットで、既存の回答の一部を検証し、恒久的な仕組みを組み込む前に判定の品質を確かめられます。

上記のTallyの動作は、2026年8月時点のTallyのドキュメントで確認したものです。