偽の登録は、偽物に見えることはほとんどありません。 アドレス、名、タイムスタンプという、ごく普通の行として届きます。 その正体が明らかになるのは後になってからで、バウンスや迷惑メール報告、成約に至らないトライアル、原因の分からないブラックリストへの掲載として現れます。 メールアドレスの偽登録を防ぐには、まず自社が直面しているのがどの種類なのかを見極める必要があります。 ボット、使い捨てのメールボックス、サブスクリプションボミング攻撃は、それぞれ別の防御をすり抜けるためです。 このガイドでは、偽登録を5種類に分類し、防御の各層が何を止めて何を見逃すのかを示します。 さらに、検証結果ごとのブロック・警告・許可のルールも紹介します。
結論から#
偽登録を1つのチェックだけで止めることはできません。 手軽な対策を重ねることで止められます。 まず手前にhoneypotフィールドとIPごとのレート制限を置き、単純なボットを除外します。 次にCloudflare TurnstileなどのCAPTCHAで、より賢いボットを止めます。 フォームではリアルタイムのメールアドレス検証を行い、配信できないアドレスや使い捨てアドレスを拒否し、入力ミスには修正案を提示します。 さらにダブルオプトインを使い、本人が確認するまでマーケティングメールが届かないようにします。 最後に、登録を流入元ごとに監視します。 そうすれば、次のキャンペーンまで待たず、数時間以内に攻撃に気づけます。
1つ、限界を覚えておいてください。 検証が判定するのはアドレスであり、入力した人がそのアドレスの持ち主かどうかは判定しません。 アドレスが実在するサブスクリプションボミングに、ほかの層が必要なのはそのためです。
偽登録の5つの種類#
「偽登録」には、性質の異なる5つの問題が含まれます。 対策はどれがフォームを狙っているかによって変わるため、作り込む前にまず診断してください。
フォームに入力するボット#
スクリプトがWebを巡回し、フォームを見つけて送信します。
実在するドメインのランダムな文字列（xk7q2v@gmail.com）、でっち上げたドメイン、収集したアドレス、盗まれたデータのテスト実行などがあります。
名前欄にスパムリンクを入れ、ウェルカムメール（Hi {first_name}）にそのリンクを配信させるものもあります。
ボットによる登録はリストを水増しします。
アドレスがでっち上げであればハードバウンスし、すべてのキャンペーンを評価するためのエンゲージメントの数値も汚染します。
使い捨てアドレス#
使い捨てのメールボックスを使う実在の人物です。
割引コードやダウンロード、無料プランが目当てで、まもなく消えるように作られたアドレスを入力します。
登録時にはメールを受信できる場合があるため、問題なさそうに見えますが、そこで自社のメールが読まれることはありません。
これらがundeliverableではなくriskyと判定される理由は、
役割アドレス、使い捨て、フリーメールの違いで解説しています。
どのドメインでも、無料の使い捨てメールチェッカーで確認できます。
偽物に見える入力ミス#
不正なアドレスがすべて悪意によるものとは限りません。
jane@gmial.comは、1文字打ち間違えただけの実在の顧客です。
ボットと同じ扱いをすれば、ワンクリックの「gmail.comではありませんか？」という提案で引き留められたはずの人を失います。
入力ミスと偽登録は区別してください。適切な対応は正反対だからです。
ブロックするのではなく、助けます。
よくあるメールアドレスの入力ミスには、入力中に検出できるほど予測しやすいパターンがあります。
サブスクリプションボミング#
ドメインに実害が及び得るのは、これです。 サブスクリプションボミング（リストボミング）攻撃では、スクリプトが被害者の実在のアドレスを、数百ものフォームに一度に登録します。 多くの場合、不正利用の通知やパスワード変更の通知を、大量のウェルカムメールで埋もれさせることが目的です。 フォームは標的ではなく、武器として使われます。
危険なのは、アドレスが実在し配信可能なため、あらゆるアドレスチェックを通過してしまう点です。 頼んでもいないメールに埋もれた被害者は、それを迷惑メールとして報告します。 その迷惑メール報告は自社ドメインの評価に響きます。 入力されたアドレスに確認なしでメールを送るフォームは、ブラックリストの運営者から見れば、まさに迷惑メールの発信源です。 そのため、フォームを経由したボミングの波によって、送信IPやドメインがリストに掲載されることがあります。 攻撃者が入力するリストに、スパムトラップが含まれている場合もあります。
無料トライアルや特典の不正利用#
同じ人物が、別のトライアル、別の初回注文クーポン、別の紹介ボーナスを狙って再び登録するケースです。
使い捨てドメイン、プラスアドレス（jane+2@gmail.com）、Gmailがドットを区別しない仕様（j.ane@gmail.comはjane@gmail.comと同じ受信トレイに届きます）、毎回新しく作ったフリーメールのアカウントなどを使い回します。
こうしたアドレスの大半は、問題なく配信できます。
問題はメールボックスではなく人物にあるため、対策は自社の重複検出で行います（入力されたとおりの値は保存しつつ、アドレスを正規化した形で比較します）。
あわせて、決済情報など、メール以外のシグナルも使います。
防御を層ごとに見る#
各層は手軽ですが、それぞれ見えないものがあります。 この順に重ねることで、互いの隙を補い合います。
| 層 | 止められるもの | 見逃すもの | 実在の利用者への負担 |
|---|---|---|---|
| honeypotフィールド | すべての入力欄を埋める単純なボット | ブラウザーのようにページを描画するボット、人間 | なし |
| IPごと・アドレスごとのレート制限 | 1つの送信元からの短時間の集中送信、同じアドレスの繰り返し送信 | 多数のIPに分散した攻撃、ゆっくり少しずつ行う攻撃 | なし（共有IPを考慮したしきい値の場合） |
| CAPTCHAまたはCloudflare Turnstile | リストボミングのスクリプトを含む、ほとんどの自動送信 | 人間が解いた、または代行業者による登録、使い捨てアドレスを使う実在の人物 | 低（Turnstileは通常、操作が不要） |
| リアルタイムのメールアドレス検証 | でっち上げ、入力ミス、存在しない、使い捨てのアドレス | 持ち主以外が入力した実在のアドレス、実在のメールボックスを使うトライアルの悪用者 | 低（問題がある場合にだけ表示） |
| ダブルオプトイン | 未確認のアドレスにマーケティングメールが届くこと、同意の記録も残る | 確認メール自体は送信されるため、別途レート制限が必要 | 中（確認しない実在の人もいる） |
| 登録の流入元ごとの監視 | 放置すれば数週間後に発覚する攻撃 | リアルタイムでは何も防げない（検知はするが、予防はしない） | なし |
honeypotフィールド#
実在の人には見えない入力欄を追加します。
type="hidden"ではなくCSSで隠してください（多くのボットは非表示の入力欄を飛ばします）。
aria-hidden="true"を付けた要素で囲み、tabindex="-1"とautocomplete="off"を指定します。
こうすれば、キーボード利用者やパスワードマネージャーがこの欄を空のままにします。
欄が埋まった状態で届いた場合は、通常の成功ページを返し、送信内容は何も言わずに破棄します。
エラーメッセージを返すと、ボットに何を変えればよいかを教えてしまうだけです。
IPごと・アドレスごとのレート制限#
制限はブラウザーではなくサーバーで行い、IPごとの送信数とメールアドレスごとの送信数の2つを数えます。 IPのしきい値は、混雑したオフィスや携帯キャリアの共有IPから出る件数を十分に上回る値にしてください。 共有IPの背後にいる実在の人が締め出されないようにするためです。 リストボミング対策では、アドレスごとの制限が最も重要です。 同じアドレスが数分のうちに何度もフォームに送信されるのが、その兆候です。 一定の期間内に、確認メールを2通以上送ることはないようにしてください。
CAPTCHAまたはCloudflare Turnstile#
チャレンジにより、リストボミングのキャンペーンを支えるスクリプトを含む、ほとんどの自動送信を止められます。 Turnstileは通常、操作がまったく不要なので、負担を低く抑えられます。 よくある間違いは、ブラウザー側だけで確認することです。 ボットはウィジェットを読み込まずに、フォームのハンドラーへ直接POSTできます。 そのため、登録を受け付ける前にサーバーがCloudflareのsiteverifyエンドポイントでトークンを検証しなければ、ウィジェットは何も守りません。
フォームでのリアルタイムのメールアドレス検証#
ボット対策を通過したら、アドレスを保存する前に、サーバーから検証APIを呼び出します。
その結果に応じて、後述の判断表に従って対応します。
ルールは2つです。APIキーはサーバー側で保持し、失敗時は通す（fail open）ことです。
呼び出しがエラーやタイムアウトになった場合は、登録を受け付け、次回のクリーニングで拾います。
サーバーレスでの登録時検証パターンに動作するコードがあります。
また、Qualisendの検証APIは、判定、理由コード、サブフラグ、did_you_meanの提案を1回のレスポンスで返します。
ホスト型のフォームビルダーは仕組みが異なります。 回答者はベンダーのページで送信するため、自社のサーバーでその場で拒否することはできません。 Qualisendの、Typeform、Jotform、Tally向けのネイティブ連携は、届いた回答を1件ずつチェックし、クリーンなエクスポートを提供します。 不正なアドレスがCRMやESPに届く前に止めたい場合は、自動化を経由して回答を渡します。 手順は、Typeform、Jotform、Tallyのガイドで紹介しています。 WordPressでは、検証フィルターを使って、エントリーが保存される前にブロックできます。 Gravity Formsのガイドと、 Contact Form 7やWPFormsを扱うWordPressフォームのガイドをご覧ください。
ダブルオプトイン#
確認リンクがクリックされるまでは、誰もマーケティングリストに追加しないでください。 これは、手前の層がすべて破られても、サブスクリプションボミングを無力化できる唯一の層です。 被害者に届くのは1通の確認メッセージだけで、ニュースレターが届き続けることはなく、未確認のアドレスがリストに加わることもありません。 この確認メールは、簡素な内容にしてください。 オファーや販促の内容を入れず、名前など、利用者が入力した項目を本文に出力しないでください。 ボットはそこから、自社のメールにリンクを紛れ込ませます。 トレードオフについては、シングルオプトインとダブルオプトインの比較で解説しています。
登録の流入元ごとの監視#
予防はいずれ破られるため、必ず気づけるようにしておきます。 登録数を、フォーム、流入元、リファラーごとに1時間単位で追跡し、通常の範囲を大きく超えた流入元があればアラートを出します。 流入元ごとに、次の3つの比率も確認してください。 検証に失敗した登録の割合、使い捨てアドレスの割合、確認率です。 クーポンのフォームで使い捨ての割合が急に上がったなら、おそらくお得情報の掲示板に投稿されています。 登録数が急増する一方で確認率が急落しているフォームは、おそらく誰かへのボミングに使われています。 有料のリード獲得フォームにも同様の問題があり、 リード広告の偽リードで扱っています。
ブロック、警告、許可：結果ごとの対応#
ボット対策の層を通過したアドレスについては、検証結果で扱いが決まります。 次が、妥当な初期設定です。
| 結果 | 意味 | 初期設定の対応 |
|---|---|---|
undeliverable（invalid_email、
invalid_domain、rejected_email） | 形式が不正、メールドメインが存在しない、またはサーバーがメールボックスを拒否した | ブロック：「このアドレスには配信できません。ご確認ください。」 |
disposableフラグ付きのrisky | 使い捨てのメールボックス | トライアル、クーポン、限定コンテンツではブロック。重要度の低いニュースレターではフラグを付ける |
did_you_meanがある | 一般的なドメインの入力ミスの可能性が高い | 警告：提案を表示し、ワンクリックで受け入れられるようにしつつ、入力したままの値も使えるようにする |
catch_allフラグ付きのrisky | ドメインがあらゆるアドレスを受け入れるため、メールボックスを確認できない | 許可してタグを付け、このセグメントのバウンスを監視する |
roleフラグ（info@、sales@） | チームで共有するメールボックス | 通常は許可。個人アカウント向けのプロダクトでは、個人のアドレスを求める |
free_mailフラグ | Gmail、Outlook、Yahooなど | 許可。B2Bのデモフォームでは勤務先のメールを求めてもよいが、ブロックはしない |
unknown | 受信側のサーバーが答えを返さなかった | 許可（fail open）して、後で再チェックする |
deliverable | メールボックスが存在する | 許可 |
上の3行は、ほぼどの事業にも当てはまります。
残りは事業によって異なります。
開発者向けツールでは、正当なadmin@の登録が見られます。
ECストアの顧客は、大半がフリーメールを使っています。
B2Bのデモフォームは企業ドメインを重視するかもしれませんが、Gmailを使う購入者を断るべきではありません。
役割アドレス、キャッチオール、フリーメールは、偽物ではなく文脈の情報として扱ってください。
タイミングについても1点あります。 即時の結果で分かるのは、構文、ドメイン、使い捨て、役割アドレス、入力ミスのチェックです。 メールボックスのチェックは、フォームが応答した後に完了することがあります。 フォームでは即時の結果に基づいて対応し、完全な結果はバックグラウンドの処理で使います（ウェルカムシリーズの開始前や、トライアルの発行前）。 こうすれば、動作の遅いメールサーバーを誰も待たずに済みます。
すでに入り込んだ偽登録を取り除く#
リストにすでに偽登録がある場合は、次の順に進めてください。
- 時間帯と流入元を特定します。 最近の登録を時間とフォームで並べ替えます。ボットの実行やボミングの波は、通常は急激な増加として現れます。普段は数件しかないフォームから、1時間に数百件の登録があります。
- そのセグメントへの送信を止めます。 次の送信の前に、そのセグメントのウェルカムシリーズと自動化を一時停止します。対応を進めている間に、バウンスや迷惑メール報告を生み続けないためです。
- セグメントを検証します。 エクスポートして一括ジョブを実行します。リストがKlaviyo、Mailchimp、ActiveCampaignなどの連携済みプラットフォームにある場合は、その場でクリーニングし、判定をタグやフィールドとして書き戻します。
undeliverableのアドレスと使い捨てアドレスは、配信を停止します。一連の流れは、リストクリーニングのガイドで詳しく解説しています。 - 検証に成功したからといって、ボミングの被害者に送り続けないでください。 リストボミングのスクリプトが入力したアドレスは実在するため、
deliverableと判定されます。攻撃の時間帯に登録され、確認も反応もしていないアドレスは、それでも削除してください。これらの人々は、自社のメールを求めたことがありません。 - その後の影響を見守ります。 続く数日間は、Google Postmaster Toolsで迷惑メール報告率を確認します。また、無料のブラックリストチェックで、送信ドメインとIPを確認します。確認を続けるより通知してほしい場合は、ブラックリスト監視が24時間ごとに再チェックし、掲載が現れたらメールでお知らせします。
- フォームを再開する前に、穴をふさぎます。 攻撃が通り抜けた層を追加してから、フォームを再び有効にします。
そのうえで、これらの対策を日々の運用に組み込んでください。 継続的な習慣はメールリスト衛生のチェックリストで、送信ドメインをブラックリストに載せないためのそれ以外の対策は、メールのブラックリスト掲載を避ける方法で解説しています。
よくある質問
01偽のメールアドレスで登録するボットを防ぐにはどうすればよいですか？
防御を重ねます。非表示のhoneypotフィールドとIPごとのレート制限で単純なボットを除外し、Cloudflare TurnstileなどのCAPTCHA（サーバーで検証）で残りの大半を止めます。それでも通過したでっち上げのアドレスや存在しないアドレスは、リアルタイム検証で拒否します。ダブルオプトインにより、未確認のアドレスにマーケティングメールが届くことを防げます。
02メールアドレスの検証でサブスクリプションボミングを防げますか？
検証だけでは防げません。サブスクリプションボミング攻撃では、アドレスが実在の被害者のものなので、配信可能と判定されます。止められるのは、検証を取り巻く層です。スクリプトを止めるCAPTCHAとアドレスごとのレート制限、そして被害者に届く確認メールを最大1通にとどめ、迷惑メールとして報告される連続したメールを防ぐダブルオプトインです。
03登録時に使い捨てメールアドレスをブロックすべきですか？
無料トライアル、初回注文のクーポン、限定ダウンロード、コミュニティのアカウントなど、価値のあるものを提供するフォームでは、ブロックすべきです。使い捨てのメールボックスは消えることを前提に作られているため、その背後の人が購読者であり続ける見込みはありません。重要度の低いニュースレターのフォームでは、後で配信停止にするためのフラグを付けるほうが、利用者への負担は小さく済みます。いずれの場合も、マーケティングメールの送信対象からは外してください。
04B2Bフォームで、Gmailなどのフリーメールをブロックすべきですか？
通常はブロックしません。フリーメールのアドレスは実在し、配信可能なメールボックスで、本物の購入者にも多くの利用者がいます。営業の進め方で企業の情報が必要な場合は、勤務先のメールを求めるか、会社名の欄を追加してください。フリーメールを一律にブロックすると、品質ではなくターゲティングの問題を解決するために、本物のリードを断ってしまいます。
05CAPTCHAだけで偽登録を止められますか？
止められません。CAPTCHAが止めるのは自動送信です。実在の人物が使い捨てアドレスや入力ミスのアドレス、使い回しのトライアルアカウントを入力するのは防げず、サーバーでトークンを検証しなければ機能しません。フォームでの検証とダブルオプトインを組み合わせ、各層がほかの層の見逃しを補うようにしてください。
06すでにリストにある偽登録を見つけるにはどうすればよいですか？
急増を探します。最近の登録を時間と流入元で並べ替え、トラフィックと合わない急増を見つけます。そのセグメントを一括で検証し、配信できないアドレスと使い捨てアドレスを配信停止にします。攻撃の時間帯に登録され、確認も反応もしていないアドレスは、配信可能と判定されても削除してください。リストボミングの被害者は、実在のメールボックスを使っているからです。
自社のフォームが何を通しているのか、確認してみませんか。 まず無料メールチェッカーで任意のアドレスをチェックし、次に検証APIで登録フローに検証を追加してください。 新規アカウントには、有効期限のない100クレジットを無料で進呈します。
