【2025年版】フォームからのスパムメール・迷惑メールへの対策方法

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は、フォームからのスパムメール・迷惑メールへの対策方法に関するもので、2025年1月6日に執筆しています。

Webサイトにはお問い合わせなどのフォームはあって当然の機能となっていますが、最近フォームからのスパムメール、迷惑メールが増えていると感じています。

そして、当社が保守を担当させていただいている企業のご担当者より、何とかしてほしいという相談をよく頂きます。

そこで、本記事では、企業のWebサイト担当の皆様に向けて、Web制作会社である当社の観点から、フォームからのスパムメール・迷惑メールへの対策方法について解説してみようと思います。

メールを専門とする企業ではなく、あくまでセキュリティ対策と技術力に多少強みを有するWeb制作会社に過ぎない当社の認識ということで、ご容赦いただけますと幸いです。

少しでも皆様のお役に立てる記事にできればと思います。どうぞよろしくお願い致します。

上記のスパムメールですが、スパムメールの送信元を偽装する「なりすましメール」や「標的型メール攻撃」など、手口も巧妙化してきており、スパムメール対策は個人・組織問わず重要であるといえます。

スパムメール・迷惑メールを放置するリスクは次の通りです。

カスタマーサポートや問い合わせフォームなどに大量のスパムが紛れ込むと、本来対応すべきユーザーからの問い合わせを見落としてしまう可能性があります。
特に「標的型メール攻撃」を受けると、一日に大量のメールが送られてくるため、顧客への対応が困難になり、顧客体験及びブランドイメージが損なわれる場合があります。

スパム対策や仕分け作業に時間を取られ、実業務の効率が落ちる原因となります。
上記の「標的型メール攻撃」の場合はもちろんのこと、スパムメールの送信元を偽装した「なりすましメール」を実施されると、その仕分けにはかなりの時間がとられてしまいます。

フィッシング詐欺の典型例は、正規の企業や金融機関などを装ったメールを送信し、メール本文内に設置したリンクから偽ページや改ざんした本物のページへと誘導して、受信者が入力したパスワード・クレジットカード情報・個人情報などを盗み取るというものです。
個人情報の盗難被害はもとより、クレジットカード番号や口座情報を抜き取られると不正利用や不正送金につながる可能性がある他、パスワードなどのセキュリティ情報が盗まれると、社内ネットワークやオンラインサービスへの不正侵入を許してしまう恐れもあります。

フィッシング詐欺と同じく、スパムメールに含まれる悪意あるリンクから誘導してマルウェアをダウンロードさせる手法の他、メールの添付ファイル（ZipやPDF、Wordファイルなど）を開かせることで、マルウェアに直接感染させる手法などがあります。
感染してしまうと、データの暗号化（ランサムウェア）や外部への情報流出など、深刻な被害につながるリスクがあります。

フォームから送信されるスパムメール（迷惑メール）に対しては、次の手法を組み合わせて対策をすること（多層防御）をお勧めいたします。

CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart）は、「コンピューターと人間を判別するための自動化されたテスト」を意味します。

具体的には、以下のような形で利用されます（GoogleのreCAPTCHAを例にします）。

GoogleのreCAPTCHA v1は文字認識を基にしており、比較的簡単に突破されるリスクがあった上に、ウェブアクセシビリティの観点からも課題があったため、現在は推奨されていません（新規のサービス提供が終了しています）。
その為、通常はreCAPTCHA v2ないしreCAPTCHA v3で実装することになります。

一方で、AIを利用してCAPTCHA v2ないしreCAPTCHA v3を突破しようとする動きも活発化しているため、他のセキュリティ対策との併用や定期的な対策強化も必要になってきています。

honeypot（ハニーポット）とは、ユーザーには見えない「ダミーのフォームフィールド」や「隠しフィールド」を設置しておき、サーバー側のフォーム処理で「ダミーフィールドに値があるかどうか」をチェックし、スパム投稿かどうか判定する手法です。
通常のユーザーはダミーフィールドが見えていない（またはブラウザ上に表示されない）ため、正しく操作してもこの項目を入力することはありませんが、スパムボットはフォーム内のあらゆるフィールドに自動的に入力して送信してくることが多いため、ダミーフィールドにも値を入れてしまうという特徴を利用して判別します。

比較的手軽に実装できるというメリットがありますが、honeypotの仕組み自体が広く知られているため、ボットによっては「非表示のフィールドを無視する」ようにプログラムされているケースもあることから、あくまで他のセキュリティ対策との併用を想定して利用する手法となります。

なお、一部のアクセシビリティツールやブラウザ拡張機能がフォームを自動補完してしまうケースがあり、この場合にメールが届かないというインシデントが発生してしまうおそれがあることを理解して利用する必要があります。

過剰送信ブロックとは、一定時間内に一定回数以上の送信が行われた場合に、その送信を制限または遮断する仕組みであり、レートリミットや投稿回数制限とも呼ばれます。

手法としては、IPアドレスごとに送信回数のカウントし、上限回数（例えば5回/分など）を超えた場合に、そのIPアドレスからのアクセスを一定時間ブロックするというものや、クッキーやセッションを利用することで、同じブラウザセッションからの送信回数をカウントし、短時間での過剰送信をブロックするなどの手法があります（ただし、IPアドレス単位の制御と比べると、匿名モードやCookie削除などで回避される確率が高いと思います）。

また、一部のWAF（Web Application Firewall）やクラウド型セキュリティサービスにはレートリミット機能が搭載されており、攻撃の種類や規模に合わせてブロックルールをチューニングできたりします。

一方で、過剰送信ブロックの設定を厳しくしすぎると、本来は正当なリクエストが弾かれてしまう確率が高まります。例えば、IPアドレスごとの上限回数を少なくしすぎると、複数人が同じグローバルIPアドレスを共有してアクセスしてくるケース（企業や公共施設など）で弾かれてしまうというようなことが起こりえます。

このため、過剰送信ブロック機能を実装する場合、テスト環境で想定シナリオをしっかり検証してから本番導入を行う必要があります。

スパムボットは基本的にJavaScriptを実行しない（または実行できるように作られていない）ケースが多いという特徴を利用して、不正投稿を見分ける対処法です。
一般的には次の3つの方法があります。

①　JavaScriptでトークンを生成し、サーバー側で検証する方法

ユーザーがフォームページを開いた段階で、JavaScriptを使って「トークン」を生成し、送信時にトークンが正しい場合のみ受付を許可するよう、サーバー側でチェックを行う手法です。
スパムボットはフォームページのHTMLやJavaScriptを無視し、直接POSTリクエストだけを送ることが多いため、トークンが生成されない（あるいは正しいトークンを入手できない）まま送信されたものを、サーバー側で「不正な投稿」と判断します。

一方で、高度なボットやヘッドレスブラウザ（JavaScriptを実行できる仕組み）を使う攻撃者には突破される可能性があること、ユーザーがJavaScriptをオフにしている場合はフォームを使えないことがあること（最近では少数だと思いますが…）などのデメリットも理解した上で、使用する必要があります。

②　ページ表示後に動的にフォーム要素を組み立てる方法

フォーム要素を初期状態では設置せず、HTML上では最低限の要素のみ表示しておき、メールアドレス欄などの実際のフォーム要素をJavaScriptで動的に生成することで、JavaScriptを実行しない（または実行できない）ボットが正しいフォーム構造を取得できないようにする手法です。
もしボットが無理やりPOSTしてきたとしても、サーバー側で「必須フィールドが存在しない」と判断して弾くなどの対応が可能です。

一方で、JavaScript依存度が高く、ユーザー側でJavaScriptが無効化されている場合は正常にフォームが使えない可能性があること、大規模サイトでは動的生成の仕組みが複雑になりやすく、メンテナンスが煩雑になる可能性があること、などのデメリットも理解した上で使用する必要があります。

③　JavaScriptによるタイミングや行動解析による方法

JavaScriptでページ読み込みから送信ボタンが押されるまでの時間・キー入力速度などを計測し、一定基準に満たない場合（例えば「ページを開いて1秒以内にフォーム送信された場合は人間ではあり得ない」など）はスパムと判定する手法や、ユーザーがどのフォーム項目にフォーカスしたか、マウス移動を行ったかなどをチェックし、「人間らしい」挙動かを判断する手法などです（これに近い仕組みがGoogleのreCAPTCHA v3に実装されています）。

一方で、実装がやや複雑で、誤判定も起きやすいこと、ヘッドレスブラウザ+スクリプトである程度の操作をエミュレートするボットには通用しない場合があること、などのデメリットも理解した上で使用する必要があります。

メールアドレスの整合性をフロントエンドないしサーバーサイドで確認することで、不整合なメールアドレスからの投稿を排除する対処法です。
一般的には次の5つの方法があります。

①　RFCに違反するメールアドレスからのメールをブロックする方法

RFC（Request for Comments）に違反するメールアドレスとは、インターネット技術の標準を定める団体であるインターネット技術標準化委員会（IETF）が発行する文書で定められている仕様・要件に準拠しないメールアドレスのことであり、例えば、「最初の文字が英数字以外であるメールアドレス」「＠の直前が英数字以外であるメールアドレス」「＠が2つ以上含まれるメールアドレス」などが典型例です。

type="email"やJavaScriptの正規表現を使い、入力時に警告を出す方法が一般的ですが、サーバー側でもチェックを行わないと、直接POSTなどで回避される可能性があります。

これにより、完全にデタラメな文字列だったり、明らかに＠が抜けているなど、明白に誤った形式のメールアドレスからのスパムメールを弾くことができますが、スパム発信者もRFCに準拠した形式でスパムメールを送ってくることが多いため、多層防御の一つとして、初歩的なエラーや明らかな偽アドレスを弾くといった役割となります。

②　DNSレコードの有無をチェックする方法

スパム送信者は、「送信ができればよく受信はできなくても良いため、MXレコードを整備しない場合がある」という特徴を利用して、入力されたメールアドレスが実際にメールを受信できるアドレスかどうかで、スパムかどうかを間接的に判定する手法です。

企業ドメインやISP提供のメールなど、正式にメールを受け付けるドメインはたいてい明示的にMXレコードを設定しており、「このサーバーでメールを受信する」と宣言しています。
そこで、サーバーサイドのスクリプトでDNSルックアップを行い、MXレコードが存在するドメインであれば一応送信可能なメールサーバーがある（ちゃんと運用されているメールアドレスである）と推定できます。

この場合、MXレコードが存在しない場合でも、MXレコードを持たないサービスや独自の受信構成をしているケースもあるため、AレコードやCNAMEを確認して受信サーバーを特定する必要があります。

一方で、一部の正規ドメイン（たとえばカスタムメールサービスや特定の企業ドメインなど）は、MXレコードの設定がユニークで、簡単なチェックだけでは「不正」と誤判定される場合もある上に、サーバー負荷が増大するおそれもあるため、実装にはかなりの知見・経験値が必要です。
このため、実際には、「スコアリング」の1要素として使われることが多い手法です（例：「MXレコードが存在しないドメインは+2点スパムスコアを付与」など）。

③　実際にメールサーバーへ問い合わせる方法（SMTP検証）

SMTPプロトコルにはVRFY（Verify）というコマンドが存在し、受信サーバーに対してメールアドレスの存在について問い合わせることができます。
しかし、多くのメールサーバーではセキュリティ上の理由からVRFYコマンドを無効にしているため、実際のところ、この手法はあまり機能しません。

また、メールサーバーに対して、実際に「RCPT TO:<メールアドレス>」を投げ、サーバーが「250 OK」を返すかどうかで存在確認を行う手法もあります。
ただし、一部のサーバーは存在しないアドレスでもとりあえずOKを返す（キャッチオール設定）場合がありますし、攻撃や大量スパムチェックと誤認されるリスクもあるため、Web制作の現場ではあまり使用されていません。

④　送信確認メールを活用する方法（ダブルオプトイン方式）

確実性の高い方法として、フォームに入力されたメールアドレス宛に確認メールを送り、ユーザーがメール内のURLをクリックするとメールを受信する（ダブルオプトイン方式）手法です。
本人以外はそのメールを受け取れないため、実在するアドレスかつ入力者本人のアドレスであることを確認できます。

一方で、ユーザーの手間が増えるというデメリットがあり、コンバージョン率（問い合わせや登録）に影響が出る可能性もあります。
このため、実際には、いわゆる会員登録フォームなど、多少ハードルがあっても許容してもらえる場合にのみ実装されているケースがほとんどです。

⑤　使い捨て（ディスポーザブル）メールドメインをブロックする方法

ディスポーザブルメールドメインとは期限限定など使い捨てのメールアドレス（例：10分間だけ有効なメールアドレスなど）を提供するサービスの総称です。
このディスポーザブルメールドメインは、スパム投稿や匿名投稿に利用されるケースが多いため、ルートドメインをブラックリストに登録して弾くという手段があります。

ブラックリストへの追加は手動で行うケースが多いのですが、ディスポーザブルドメインのリストは日々増えており定期的なアップデートが必要であること、まれにテスト用途などで正規のユーザーが使うケースもあるため、届くべきメールが届かないといった場合もありえること等を理解しておく必要があります。

特定のIPアドレスやドメインが頻繁に悪意ある投稿を行う場合に、ブラックリスト登録によってアクセスや投稿を遮断する対処法です。
一般的には次の5つの方法があります。

①　個別ブラックリストを作成し遮断する方法

攻撃やスパム投稿を検知するたびに、問題のあるIPアドレス・ドメインを手動でブラックリストに登録して遮断する方法です。

通常はWebサーバーやファイアウォールレベルで特定のIPアドレスをブロックしていきます。
悪意のあるメールがアプリケーションに到達する前にブロックできるというセキュリティ上のメリットはありますが、ブラックリストへの追加は通常手動で行うため運用コストの課題はあります。

一方で、WordPressなどのCMSでは、管理画面でスパム元のIPアドレスやドメインを拒否設定できるプラグイン（Wordfence SecurityやAll-In-One Security）があります。
IPリストの管理・更新がWordPressの管理画面から容易にできるため手動での追加工数を若干削減できる一方で、悪意のあるメールがPHPレイヤーまで到達してしまう上に、サーバーリソースを多少消費してしまうというデメリットもあります。

②　外部ブラックリスト/ RBL（Realtime Blackhole List）を活用し遮断する方法

迷惑メールをブロックするサービスは各プロバイダ毎に提供されていますが、実際にはそれを通過して到達するため、それよりも検知精度や頻度が高い外部サービス（Stop Forum Spamなど）を利用する方法です。

多くのスパムボットのIPアドレスや、攻撃を繰り返すホストが既に登録されているケースがあるため、導入すれば即座にスパム投稿を削減できる場合がありますが、外部リストによっては誤判定や古い情報が含まれている可能性もあります。

③　国別IPブロックで遮断する方法

アクセス元の国コード（GeoIP）情報を基に、特定の国・地域からのアクセスを遮断する方法です。

対象サイトのビジネス範囲が特定地域に限定されている場合、特定の国・地域からのアクセスが不要であれば一括ブロックで被害を大きく減らせる可能性がありますが、一方で、海外からの正当なユーザー（旅行中の既存顧客など）をブロックしてしまうリスクがある上に、軽々にアメリカをブロックするとGooglebotやBingbot（両方とも主に米国IP）をはじめとする、検索エンジンのクローラーがアクセスできなくなる可能性が高いため、検索結果にヒットしなくなるリスクがあります（GoogleなどのIPアドレスをホワイトリストにいれたり、リバースDNSを用いて、アクセス元がgooglebot.com になっているかをチェックし通過させる方法などで回避できますが、いずれにせよ対応コストがかかります）。

④　Tor出口ノード（Tor Exit Node）をブロックする方法

匿名ネットワーク（Tor）を経由したアクセスを拒否する方法です。

Torは本来的にはプライバシー保護の目的で使われるべきものですが、近年スパムや攻撃に悪用されるケースが多くなっているため、Tor出口ノードをブロックする手法は有効です。

一方で、Torを経由していないスパムも多くある上に、Torノードリストは頻繁に変わるため、常に最新の出口ノード情報を更新・参照する必要があり、運用上のコストがかかるという課題があります。

⑤　WAF（Web Application Firewall）によるアクセス制御をする方法

Cloudflare、AWS WAF、Azure WAFなどのクラウド型サービスや、ModSecurityなどのオンプレ型WAFを使い、スパムと確認されたIPアドレスやドメインをブロックルールとして設定する方法です。

攻撃パターンごとのシグネチャやIPレピュテーション、ドメインレピュテーションを参照して自動的に遮断できるため、手動管理が不要になる場合もあります。

一方で、導入・運用コストがかかる上に、誤検知が起こる可能性もあります。
通常、この誤検知をできるだけ減らすために、導入直後にWAFの設定、チューニングを行いますが、セキュリティやネットワーク及び使用するWAFに関する高度な知識が必要なため、設定・チューニングにもコストがかかるという課題があります。

前述のように、WAFを導入することで、レートリミット機能を使用したり、スパムと確認されたIPアドレスやドメインをブロックルールとして設定することでフォームからのスパムメールを遮断する方法です。

当社の主観ではありますが、大規模サイトや企業サイトでは、セキュリティソリューションとしてWAFを利用することは「あたりまえ」となってきていますので、通常は、このWAFを最大限活用してスパムメール対策を実施していくことになります。

近年、Google WorkspaceやExchange Online Protectionなどの有名どころだけではなく、メールサーバーを提供しているサーバー会社などから、高性能なスパムフィルタ、AIによる迷惑メールフィルタの提供がされるようになってきました。
参考：さくらのレンタルサーバ、AIを活用した予測型メールフィルタリング機能「高精度迷惑メールフィルタ」を無料で提供開始

こういったフィルタは各社ごとに設定方法や無料で使用できる範囲が異なるため、まずはお使いになられているメールサーバーのスパムメールフィルタがしっかりと設定されているかを確認するとよいでしょう。

とはいえ誤判定はありえます。
無料プランでは詳細なログが参照できず、どんな理由でスパム判定されたかがわからない場合があるため、有料プランにしたうえで「詳細レポート」や「リアルタイム監視画面」を使用し、運用担当者が誤判定を素早く発見・修正できる運用体制を整えるなど、検討すべき課題もあります。

なお、WordPressの場合には、Akismet Anti-Spamというフィルタリングプラグインがありますが、Akismet Anti-Spamは一度スパムをWebサーバーに入れた上で、スパムを振り分けるプラグインであることから、多少なりともサーバーリソースを消費してしまうという課題もあります。

クラウド型セキュリティサービスは通常、CDNを利用したコンテンツ配信・キャッシュ最適化に加え、DDoS緩和、WAF、レートリミット、ボット管理、SSL/TLSターミネーションなど、包括的なセキュリティ・パフォーマンス管理機能を備えたサービスです。

前述のCloudflareのWAFも、Cloudflareというクラウド型セキュリティサービスのWAF機能と位置付けてよいでしょう。

CDNの段階で通常の流入経路と怪しいトラフィックを区別し、スパムボットのアクセスを事前に弾く（そもそもスパムボットがフォームにたどり着けない）ため、セキュリティ面でも一番安心であり、かつフォーム送信への攻撃を包括的に防げる点がメリットですが、設定コストや誤判定を修正するためのチューニングコストがかかる点はWAFと同様です。

なお、EU一般データ保護規則（GDPR、General Data Protection Regulation）の順守が求められる企業の場合で、米国に拠点を持つクラウド型セキュリティサービス（CDN＋WAF）を導入する場合、これらのサービスは一般的にトラフィックを複数の海外サーバーに中継するため、EU域外への個人データ移転が生じる可能性があります。
もうこのあたりは、企業の法務部の皆様と当社のようなベンダーがいかにしてクリアするかをケースバイケースで検討するしかない状況です。

送信ドメイン認証とは、メール送信時に本人確認情報も一緒に送ることで、メールサーバーがメールを受信したときに、その送信元が信頼できるかどうか（なりすましメールでないかどうか）を認証する仕組みです。

例えば、GoogleはGmailの「メール送信者のガイドライン」を改訂し、2024年2月1日以降は、Gmailにメールを送信するすべての送信者は、送信元ドメインに SPFまたはDKIMを設定する必要がる（1日に5000件を超えるメールを送信する場合には、送信元ドメインにSPFおよびDKIM並びに DMARCメール認証を設定する必要がある）としました。

SPF・DKIM・DMARCについては次の通りです。

①　SPF（Sender Policy Framework）設定を要求する方法

SPFは「このドメインからメールを送信してよいIPアドレス（サーバー）はどれか」をDNSレコードで宣言する仕組みです。
メール受信側は、送信ドメインのSPFレコードと実際の送信元IPアドレスを照合し、一致しない場合に「なりすましの疑いがある」と判断します。

受信側としては、DNSレコードで許可IP（サーバー）を定義するだけなので導入は比較的工数がかかりませんが、送信側にてSPFを設定する必要がある点で、現時点ではSPFないしDKIMを設定していない正規のメールを弾いてしまう可能性があります（とはいえ国内のメールサーバー会社はほぼSPF・DKIMについては標準設定としています）。

②　 DKIM（DomainKeys Identified Mail）設定を要求する方法

DKIMは、送信ドメインがメール本文に電子署名を付与し、受信側が公開鍵を使ってその署名を検証する技術です。
メールに署名（暗号学的なハッシュ値）を付与することで、「改ざんされていないか」「本当にそのドメインが署名したものか」を確認でき、署名が検証に失敗した場合、なりすましや途中改ざんの疑いが高いものとして扱うことができます。

送信側にてDKIMを設定する必要がある点で、現時点ではSPFないしDKIMを設定していない正規のメールを弾いてしまう可能性がある点はSPFと同様です。

③　DMARC（Domain-based Message Authentication, Reporting & Conformance）設定を必須にする方法

DMARC（ディーマーク）は、SPFやDKIMの検証結果を活用して「なりすましをどのように処理するか」をポリシーとして示す仕組みです。
送信ドメインの管理者がDNSにDMARCレコードを設定し、SPF・DKIMのいずれか（または両方）の検証が失敗した場合に、受信側に対して「メールを拒否」「迷惑メールフォルダに入れる」などの処理を要請できる他、レポーティング機能があり、受信メールのSPF・DKIM検証結果をレポートとして送信元に返すことができます。
これにより、管理者はどの程度のメールが正しく認証され、どの程度がなりすまし扱いされたかを把握できます。

送信側にてDMARCを設定する必要がある点で、現時点ではDMARCを設定していない正規のメールを弾いてしまう可能性がある点はSPF・DKIMと同様です（SPF・DKIMと異なり、国内のメールサーバー会社では任意としている印象です）。

上記のように、送信ドメイン認証がGoogleでも採用され、世の中は急速に送信ドメイン認証を必須とする方向に進んでいることから、近い将来送信ドメイン認証が必須となる時代が来るものと当社では考えております。

しかしながら、送信ドメイン認証を設定する場合、SPFやDKIM、DMARCのレコードを正しく設定しないと、正当なメールが弾かれたり、認証失敗する恐れがあるため慎重に設定を行う必要がある他、メールマガジンサービスや顧客管理サービスなど、複数のサービスからメールが送られるケースがあるため、それぞれのサービスに合わせてSPFやDKIMの設定を行わなければならない他、DMARCポリシーを「reject（拒否）」レベルに設定する場合は、テスト運用やレポートの確認などをしっかり行い、思わぬブロックが発生しないよう注意する必要がある等、越えなければならないハードルがいくつかあるのが実情です。

その為、ご利用になられているメールサーバーが、Gmailのように送信ドメイン認証を必須とし、設定変更をサーバー側にて一括で行ってくれることを待つという選択肢もあるかと考えております。

ここまでは、フォームから送信されるスパムメールへの対策について、セキュリティと技術力に多少の強みを有するWeb制作会社の知見を公開してきました。
一方で、例えば極端な対策として「フォームをなくす」という手法をとったとしても、スパムメールが送りつけられるケースがあります。

この原因は色々と考えられますが、基本的には、何らかの理由によりメールアドレス販売業者のリストにメールアドレスが掲載されていることが疑われます。

このようなフォームと関係なく送り付けられるスパムメールに対しても、下記の方法は一定の効果を発揮します。

・過剰送信ブロック（レートリミット）を実装する方法
・メールアドレスを検証する方法
・個別ブラックリストを作成し遮断する方法
・外部ブラックリスト/ RBL（Realtime Blackhole List）を活用し遮断する方法
・スパムフィルタ・AIによる迷惑メールフィルタを活用する方法
・送信ドメイン認証（SPF・DKIM・DMARC）を採用する方法

一方で、フォームと関係なく送り付けられるスパムメールに対する最も簡単な対策は、フォーム専用のメールアドレスを変更してしまうことです。

お問い合わせ用のメールアドレスを、あくまでお問い合わせを受けるためだけの仕様に留めておき、フォームと関係なく送り付けられるスパムメールを発見したらフォームのメールアドレスを変更してしまうという対策は、シンプルですが非常に有効です。

上記のように、スパムメール・迷惑メールへの対策は多層防御が基本となります。

しかしながら、どのような手法にも誤検知・誤判断のおそれはありますし、それぞれの環境によって選択すべき対策手法は異なってきます。
また、対策を実施しようにも知見が必要であったり、設定が複雑であるなどの問題に直面することもあるかと思います。