最終更新：2026年9月2日
迷惑メールが来たら、まず送信経路を確認する
受信箱へ届いた迷惑メールが、WEBフォームから送られたとは限りません。フォーム通知と同じ件名・形式か、入力内容が含まれているか、フォーム側の履歴があるかを確認します。メールアドレスへの直接送信には、フォームへ認証を追加しても効果がありません。
フォーム経由かを切り分ける
| 通知形式 | フォーム固有の件名、項目名、受付番号があるか確認します。 |
|---|---|
| 送信履歴 | WordPress、フォームサービス、サーバーログに同時刻の記録があるか確認します。 |
| 送信元 | フォーム通知用アドレスと、迷惑メールの送信経路を比較します。 |
| 対象フォーム | 問い合わせ、採用、資料請求など、どこから送信されたか特定します。 |
対策前の発生状況を記録する
- 1日・1週間あたりの迷惑送信数
- 発生した日時、対象フォーム、言語、URL数
- 同じ内容、IP、メールアドレス、ドメインの繰り返し
- 正規問い合わせ数と、迷惑メールへ誤分類された件数
- 現在使用している認証、プラグイン、メールフィルター
対策後の効果を判断するため、導入前の基準を残します。本文や個人情報の共有範囲には注意してください。
一つの対策だけに依存しない
Turnstile・reCAPTCHA
利用者の操作やブラウザ情報を使って自動送信を判定します。サイトの利用者とフォームに合う方式を選びます。
サーバー側検証
認証サービスが返すトークンを送信処理側で検証し、失敗したリクエストを保存・送信しません。
頻度制限
同じ送信元から短時間に繰り返される送信を制限します。共用回線や社内ネットワークへの影響を考慮します。
入力検証
隠し項目、URL数、禁止形式、文字数などを補助的に使います。特定言語だけを一律拒否しないよう注意します。
認証結果はサーバー側で確認する
Turnstileなどのウィジェットを表示しても、サーバー側の送信処理が検証しなければ、攻撃者はフォーム画面を経由せず送信できます。秘密鍵はブラウザへ公開せず、サーバー側から公式の検証APIへ送ります。
- トークンが存在するか
- 公式検証APIが成功を返したか
- 想定するホスト名・アクションか
- 期限切れや同じトークンの再利用ではないか
- 検証に失敗した場合にメール送信・保存を止めるか
Cloudflareはサーバー側検証を必須としており、トークンには有効期限と一回限りの制約があります。詳細はTurnstile公式ドキュメントで確認します。
正規利用を止めていないかテストする
- PC・スマートフォン、主要ブラウザから正常送信できる
- 入力エラー後も再入力・送信できる
- 自動返信と担当者通知が届く
- 認証失敗、期限切れ、二重送信が適切に処理される
- JavaScriptを読み込めない場合の案内が分かる
- プライバシーポリシーに外部認証サービスの利用を反映する必要がないか確認する
導入後も件数を確認する
スパムがゼロになることだけを目標にすると、正規の問い合わせまで拒否する設定になりがちです。迷惑送信数、正規問い合わせ数、フォームエラー、利用者からの申告を確認し、必要な範囲で調整します。