問い合わせフォームのメールがスパムに入る — ウェブサーバー送信者の修正方法（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

問い合わせフォームやウェブサイトのメールがスパムに入るのは、ウェブサーバーが認証なしで送信しているからだ — SPF の認可なし、DKIM 署名なし。信頼できる修正は、サーバーをホワイトリストに登録するのではなく、そのメールを認証済み SMTP 経由でルーティングすることだ。Defaults.Exposed センサス（2026-06-29 時点データ）で採点された 261,086,232 ドメインのうち 46.4% は SPF レコードを全く公開していない。

修正の順序が重要で、ほとんどのチュートリアルは逆から説明している。無料スキャンを実行してドメインが実際に何を公開しているか確認し；サイトのメールを認証済み SMTP（メールボックスプロバイダーまたはトランザクションメールサービス）経由でルーティングして本物の DKIM 署名を得る；フォームの From アドレスを修正する；そしてサーバーの IP を SPF に追加するのは最後の手段としてのみ。

ウェブサイトからのメールがなぜスパムに入るのか？

誰が本当に送信しているかのせいだ。訪問者が問い合わせフォームを送信すると、メールはメールプロバイダーからではなく、ウェブサーバー自体が通常 PHP の mail() を通じて生成する。受信側から見ると、そのメッセージは：

SPF レコードが認可していない IP から来る（SPF はメールプロバイダーをカバーしており、ウェブホストではない）；
DKIM 署名がないため、暗号的にドメインに結び付けるものが何もない；
多くの場合、レピュテーションが他の何百ものサイトによって設定される共有ホスティング IP から送信される。

評判が混在する IP からの未認証メールは、まさにスパムフィルターが捕まえるものだ — Gmail と Outlook には、あなたのフリを装うランダムなサーバーが見える。より広いベースラインは厳しい：46.4% のドメインが SPF を全く公開しておらず、DMARC ポリシーを適用しているのはわずか 10.59%（採点済み 261,086,232 ドメインの 27,640,987、2026-06-29 センサス）だ。

なぜこれが特に WordPress サイトに影響するのか？

WordPress はすべてのメール — フォーム通知、パスワードリセット、注文確認 — を1つの関数 wp_mail() を通じて送信する。デフォルトではウェブサーバー上の PHP mail() をラップする。意図的に再設定されていないすべての WordPress サイトはデフォルトで認証されていない送信者だ。フォームプラグイン（Contact Form 7、WPForms、Gravity Forms）はすべて同じ関数にメールを渡す：プラグインの問題に見えるが、トランスポートの問題だ。

修正は別のフォームプラグインではなくSMTP プラグイン（WP Mail SMTP とその同等品）だ。wp_mail() が送信するものすべてを実際の認証済みメールアカウント経由でリルートする — SPF がすでに認可しているインフラで、DKIM 署名が付く。

サイトはどの送信方法を使うべきか？

送信方法	SPF	DKIM	ホスト移行に耐えられるか？	判定
PHP `mail()` / デフォルトの `wp_mail()`（ウェブボックスから）	失敗	なし	n/a — どこでも壊れる	問題であり、選択肢ではない
メールボックスプロバイダー（Google Workspace、Microsoft 365 など）経由の認証済み SMTP	合格	署名あり	はい — ホスティングから独立	ほとんどのサイトの修正
ドメインが検証済みのトランザクションメールサービス（SES、Postmark、Brevo など）	合格	署名あり	はい	ボリューム時の修正（EC、大規模フォーム）
SPF レコードに追加されたウェブサーバーの IP	合格（SPF のみ）	なし	いいえ — IP が変わると静かに壊れる	フォールバックのみ — 下記参照

1日に通知を数件送るだけなら、すでに支払っているメールボックス経由の SMTP が最短の道；実際のボリュームでは、トランザクションサービスがそれ向けに構築されている。どちらも DKIM を提供する — IP ホワイトリストの近道は提供しない。

問い合わせフォームのメール到達性を修正するには？

何かを変更する前に defaults.exposed で無料スキャンを実行する。 ドメインが実際に公開している SPF、DKIM、DMARC を表示する — フォームのトランスポートを修正しているのか、欠落したレコードを修正しているのか、両方なのかが分かる。SPF が全くない？ SPF の修正方法から始める。
サイト専用の SMTP アイデンティティを作成する — 例えばメールボックスプロバイダーの [email protected]、またはトランザクションサービスの検証済み送信ドメイン。個人のメールボックスパスワードではなく、取り消し可能なアプリパスワードまたは API キーを使用する。
サイトのメールをそこ経由でルーティングする。 WordPress：SMTP プラグインをインストールしてそのアカウントに向ける。他のスタック：ローカルの mail() の代わりにフレームワークのメーラーを設定する。
From アドレスを修正する（下記のアンチパターン）：From は自ドメイン；訪問者は Reply-To に入れる。
送信者がトランザクションサービスの場合は DKIM レコードを追加する（通常は CNAME が2件）。メールが自ドメインで署名されるようになる — DNS ステップは SPF 設定ウォークスルーを反映している。
テスト送信を行い再スキャンする。 ヘッダーにあなたのドメインで spf=pass と dkim=pass が表示されるはずだ；次に SPF の修正と DKIM の修正でスキャンがフラグを立てたものをクリアする。

なぜフォームが訪問者のメールアドレスから送信しているのか？

フォーム設定で最も一般的な自業自得の傷で、多くのプラグインがデフォルトでそうしていた：通知が訪問者のアドレスから届くため、返信できる。便利に感じるが、偽造だ。サーバーは [email protected] としてメールを送る権限がない — gmail.com の SPF と DKIM で失敗し、Gmail の DMARC ポリシーが受信側に迷惑メール判定または拒否するよう指示する。修正は無料だ：

From： 自ドメインのアドレス（ステップ2の SMTP アイデンティティ）
Reply-To： 訪問者のアドレス — 返信はまだそこに直接届く

すべての主要なフォームプラグインがこれをサポートしている；通知設定の2つのフィールドだ。

なぜサーバーの IP を SPF レコードに追加するだけではいけないか？

ほとんどのフォーラムスレッドが最初に目を向ける修正で、フォールバックである理由がある。SPF に ip4:<server>（またはウェブホスト用の a メカニズム）を追加するとチェックは合格するが：

共有ホスティングでは他者を認可する。 IP はあなたではなくボックスに属している；そのサーバー上の他のすべてのサイトが今やあなたのドメインとして SPF 合格のメールを送れる。
静かに壊れる。 ホストは通知なしにサーバーを移行し IP をローテーションする；SPF は数ヶ月前に去ったアドレスを認可し続ける。
DKIM が得られない。 SPF だけでは転送で壊れ、署名が DMARC 適用に向けて進める方法では進められない。

本当に制約されたケースのみにこのルートを残す：あなたがコントロールする静的 IP を持つ専用サーバーと、SMTP で通信できないアプリケーション — そして可能なら DKIM 署名をボックスに追加する。

SPF はフォームが「From」に入れたアドレスをチェックするのか？

いいえ — これが DIY 診断の半分を混乱させる。受信側は SPF を From ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメインに対して評価する。ウェブサーバーは多くの場合、Return-Path に自分のホスト名をスタンプするため、SPF レコードがそもそも参照されなかった — 受信側は srv0421.examplehost.com の SPF をチェックした。認証済み SMTP もこれを修正する：Return-Path があなたのドメインになり、SPF の合格がついにあなたのためにカウントされる。DKIM が重要な理由もここにある — DMARC アライメントは From のドメインに結び付いた合格が必要で、DKIM 署名はメッセージと共に移動する。

よくある質問

SMTP プラグインはパスワードリセットや WooCommerce のメールも修正するか？ はい。WordPress では wp_mail() を通じてすべてが流れるため、リルートするとフォーム通知、パスワードリセット、注文メールが一度に修正される。

SMTP プラグインを使っても SPF と DKIM レコードが必要か？ はい — プラグインはメールを送信するインフラを変更する；レコードはそれを認可するものだ。ドメインが採点済み 261,086,232 ドメインの 46.4% のうちの SPF レコードなし（2026-06-29 センサス）に含まれる場合、認証済み SMTP だけでは助からない。新しいドメインのメールチェックリストが完全なレコードセットをカバーしている。

フォームメールが SPF は合格するが DMARC で失敗する — なぜか？ ほぼ常に上記の From なりすましのアンチパターン、またはあなたのドメインではなくホストの Return-Path ドメインで SPF が合格している。まず From/Reply-To を修正する；それでも失敗する場合は、欠けているのはアライメントされた DKIM 署名だ — 「DKIM signature not valid」を参照。ウェブサイト以外の SaaS ツールも失敗している場合は、SaaS ツールで SPF が失敗するガイドが修正の順序をカバーしている。

トラフィックの少ない問い合わせフォームのためにこれをやる価値はあるか？ フォームは通常お金が入ってくる場所だ — 見逃した問い合わせは失ったことも知らない顧客だ。そして修正は無料だ；障壁はウェブサーバーがずっと認証されていない送信者だったと知ることだ。

オーナーにレポートを送る

これを修正している開発者またはコントラクターなら：テスト送信が合格したら、無料スキャンを再実行し、サイトのオーナーに採点レポートを転送する — ドメインが適切に認証していることを示す、日付入りの平易な記録であり、次のサイバー保険更新や顧客セキュリティアンケートに必要な成果物だ。問い合わせが届かなくなったためにこれを読んでいるオーナーなら：このページとスキャンレポートをウェブサイトを管理している人に送る — 前後を見せられる、午後1つの作業だ。

ドメインをチェックする → · SaaS ツールで SPF が失敗する？ → · SPF を修正する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。