問い合わせフォームの迷惑メールが多い日は約20件。Turnstile導入後0件になった事例
弊社サイトの問い合わせフォームには、多い日で20件程度の迷惑メールが届いていたことから、利用者に画像選択などの操作を求めずに導入できる対策の検討を始めました。
選んだのは、Cloudflare Turnstileとハニーポットの組み合わせで、段階的に導入したところ、その後1週間の迷惑メールは0件でした。正常送信のテストだけでなく、実際の問い合わせ受信も確認できています。
本記事では、Turnstileを選んだ理由から、既存のステップ式フォームへ導入するときに配慮した点まで、弊社での実例をもとに紹介します。
なぜ問い合わせフォームの迷惑メール対策が必要になったのか？
対策を始めたきっかけは、サイト内の問い合わせフォームへ届く迷惑メールが増え、多い日には20件程度に達していたことでした。
社内でも対策が必要だと判断した一方、問い合わせをする利用者へ画像選択などの操作を求め、送信の負担を増やすことは避けたいという考えもありました。
そこで条件にしたのが、利用者の操作をなるべく増やさず、既存フォームへ追加できる方法です。
なぜCloudflare Turnstileを選んだ？
Cloudflare Turnstileを選んだ理由は、利用者に画像選択を求めずに導入でき、無料プランが用意され、Cloudflare経由で配信していないサイトでも利用できるためです。
Cloudflareがボット対策に取り組んでいることへの信頼も、選定を後押ししました。Cloudflareのプラン説明によれば、無料プランでもすべてのウィジェット形式と無制限の検証リクエストを利用でき、Turnstileの導入ガイドには、Cloudflareのネットワークを経由していないWebサイトでも独立して利用できると記載されています。
ただし、無料なのはTurnstileのサービス利用に限られ、既存フォームへ組み込む作業まで不要になるわけではありません。画面へウィジェットを置くだけでなく、サーバー側で送信内容を検証する実装が欠かせないためです。
Turnstileとハニーポットはどのような順序で導入した？
弊社では、まずTurnstileを導入。続いて、単純なボットをよりシンプルな方法で除外するためにハニーポットを追加しました。
ハニーポットは、通常の利用者には見えない入力欄をフォームへ用意し、その欄へ値を入れた送信を自動入力と判定する仕組みです。弊社では、複雑な判定を行う前に単純な自動送信を除外し、残った送信をTurnstileで検証する二段構えにしています。
実装では何に注意した？
実装時に特に注意したのは、ウィジェットを表示するタイミング、サーバー側のトークン検証、秘密鍵の保管場所の3点です。
弊社の問い合わせフォームは、入力、確認、送信と進むステップ式です。トークンは発行から5分で失効するため、入力中に期限切れとなる可能性を抑えられるよう、ウィジェットを設置したのは送信直前の最終確認画面だけでした。
フォームを送信すると、Turnstileが発行したトークンもPHPへ渡ります。そこからCloudflareのSiteverify APIへトークンを送り、検証結果とホスト名を確認したうえで、条件を満たす問い合わせだけがメール送信へ進む構成です。
Cloudflareのサーバー側検証ガイドでも、ウィジェットの表示だけではフォームを保護できず、Siteverify APIによる検証が必須とされています。トークンは5分で失効し、一度しか検証できないため、画面側とサーバー側を一組にした実装が欠かせません。
実装では、通常の問い合わせが最後まで送信できる経路を残しつつ、ハニーポットに値が入った送信や、Turnstileのトークンが無効な送信はメール送信へ進めない構成にしました。
導入後、迷惑メール件数はどう変わったか？
導入前には多い日で20件程度届いていた迷惑メール。Turnstileとハニーポットの導入後は0件になりました。
同じ期間に正常送信のテストを行い、問題なくメールを受信できることも確認済みです。実際の問い合わせも届いているため、現時点では通常の問い合わせへの影響は見られていません。
これは弊社サイトの問い合わせフォームにおける1週間の観測結果に限られ、すべてのサイトで同じ結果を保証するものではありません。それでも、利用者の操作を大きく増やさずに実施できる対策として、導入後の状況を引き続き確認していく価値があると考えています。
自社フォームへ導入するときは何を確認すればよいか？
Turnstileは無料で利用できますが、既存フォームの構成、サーバー側のトークン検証、秘密鍵の管理まで含めて導入方法を検討する必要があります。
導入前に確認したいのは、少なくとも次の5点です。
- フォームのどの画面でウィジェットを表示するか
- サーバー側でSiteverify APIを呼び出せるか
- 秘密鍵を公開領域の外で管理できるか
- 正常な問い合わせと、不正な送信の両方をテストできるか
- 導入後の迷惑メール件数と正常な問い合わせを継続して確認できるか
WordPressや外部フォームサービスを利用している場合は、Turnstileのウィジェットやサーバー側の検証処理を追加できるか、事前に確かめておきたいところです。
無料で使えるサービスでも、ウィジェットを設置するだけで迷惑メール対策が完了するわけではありません。フォームの画面と送信先の両方を確認し、既存フォームの構造に合わせて実装する必要があります。初回相談は無料ですので、既存フォームに導入できるか分からない段階でも、お気軽にLoveAllのお問い合わせフォームからご相談ください。
広告、SEO、AIを活用したマーケティング業務の自動化を得意としています。