WordPressから大量の迷惑メールが送信された時の止め方｜wp_mailとSMTPログを確認

WordPressから突然、大量の迷惑メールが送信され、サーバー会社から警告を受けて困っていませんか？
メールアドレスを変えるだけでは止まらず、正規のお問い合わせ通知まで届かなくなると、何から確認すべきか判断しにくくなります。

この時に大切なのは、慌ててプラグインを全部削除することではありません。
送信を安全に止め、メールの証拠を残し、WordPressの処理・SMTP認証・メールボックス侵害を分けて調べることです。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、大量送信を止める初動と、wp_mail・SMTPログから発信元を追う順番を解説します。

結論から言うと、最初は「全メールを止める」「犯人を決める」の二択にしないことが重要です。
送信経路ごとに一時停止し、残したログから発信元を特定すれば、正規メールへの影響を抑えながら復旧できます。

この記事では、初心者でも作業の目的を見失わないよう、停止、証拠保全、経路判定、WordPress内部調査、復旧テストの順で説明します。
現在も大量送信が続いている場合は、まず次の初動から始めてください。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressから迷惑メールが大量送信された時は証拠を残して止める

WordPressから迷惑メールが大量送信された疑いがある時は、証拠を保存してから、影響する送信経路だけを一時停止します。
送信元を消してしまうと、再発時に同じ侵入口を見逃しやすくなるためです。

サーバー会社の警告メール、送信数グラフ、エラー時刻、差出人、宛先例を保存し、時刻をJSTへ統一して作業メモに残します。
本文に個人情報がある場合は、共有用コピーだけをマスキングし、原本はアクセス制限した場所へ保管してください。

WordPressの大量送信で最初に保存する情報

最初に必要なのは、迷惑メールそのものだけではありません。
メールヘッダー、送信開始時刻、SMTPユーザー、送信元IP、エンベロープFrom、Message-IDが分かると、WordPress・SMTP・メールボックスのどこを優先して調べるか決めやすくなります。

ヘッダーのReturn-Pathと画面上のFromは、同じとは限りません。
表示名だけで送信元を決めず、Received、Authentication-Results、Message-IDのドメインも合わせて確認します。

大量送信の停止はメール経路ごとに行う

大量送信が続いているなら、レンタルサーバーやSMTPサービスの送信停止・資格情報失効を優先します。
ただし、注文通知、パスワード再設定、問い合わせ通知も止まる可能性があるため、停止時刻と影響する業務を同時に記録してください。

不審なPHPが特定できている場合は、原本を保全してから公開領域外へ隔離します。
まだ発信元が不明なら、WordPress全体を削除せず、アクセス制限やメンテナンス表示で新しい実行を減らしながら調査を続けます。

送信停止は復旧ではなく、被害拡大を止める封じ込めです。
メールが止まったあとも、資格情報、ファイル、データベース、管理者、Cronを確認しなければ再開できません。

クイックレスキュー

WordPressのマルウェア感染でメールも危険？サイト外へ広がる被害の確認方法

WordPressのwp_mailとSMTP悪用を分けて送信元を判断する

WordPressのwp_mailが使われたか、SMTP資格情報が外部から悪用されたかは、別の問題として判定します。
WordPress画面に異常がなくても、漏えいしたSMTPパスワードやメールボックスから直接送られる場合があるためです。

WordPressのwp_mail()は、通常PHPMailerを通してメールを組み立てます。
SMTPプラグインがあれば外部SMTPへ渡し、なければサーバー側のメール送信機能へ渡すため、関数名だけでは最終経路を断定できません。

wp_mailの成功は相手への配信完了を意味しない

WordPress公式リファレンスでも、wp_mail()がtrueを返すことは、処理がエラーなく受け付けられたことを示すだけです。
受信箱への到達や迷惑メール判定まで保証するものではありません。

そのため、WordPressのデバッグログに失敗がなくても、SMTP側の拒否、キュー滞留、宛先側のブロックは残り得ます。
WordPress、SMTP、受信側の三段階で結果を分けて記録してください。

WordPress経由か外部SMTP悪用かを比較する

WordPress経由なら、送信時刻の前後にフォーム送信、REST API、admin-ajax.php、WP-Cron、Action Schedulerなどの要求が残ることがあります。
同時刻にPHPファイル更新や不審な管理者操作があれば、関連を時系列で確認します。

一方、WordPressへのアクセスやPHP実行がなくても送信が続く場合は、SMTPアカウント、Webメール、外部メールアプリ、APIキーの悪用を疑います。
SMTPサービスの認証ユーザー、接続IP、クライアント名を確認し、WordPressのログだけで結論を出さないでください。

WordPressの迷惑メールはSMTPログとメールヘッダーから追跡する

迷惑メールの発信元を追う時は、完全なメールヘッダーとSMTPログを同じ時刻で照合します。
件名や差出人名は容易に偽装できても、配送経路・認証結果・キューIDには調査に使える情報が残るためです。

メールヘッダーは下から上へ配送経路を確認する

Received行は、一般にメールが通過するたび上へ追加されます。
一番下に近い行から読み、最初に受け取ったサーバー、時刻、送信元IP、HELO名を確認すると、どのサービスから始まったか整理しやすくなります。

ただし、ヘッダーの一部は送信者が追加できるため、受信サービスが付けた認証結果を優先します。
SPF、DKIM、DMARCがpassでも、正規SMTP資格情報が盗まれていれば迷惑メールは正規認証を通ることがあります。

SMTPログでは認証ユーザー・接続IP・キューIDを見る

SMTPログを確認できる場合は、認証ユーザー、接続元IP、キューID、宛先、応答コードを追います。
同じキューIDがヘッダーや配送ログに残っていれば、どの認証経路から投入されたかを結び付けられます。

共有サーバーでは生ログを利用者が見られない場合があります。
その時はサーバー会社へ、発生日、Message-ID、差出人、宛先例、送信元ドメインを伝え、該当時刻の認証方式と実行元の確認を依頼してください。

メールキューは削除前に件数と代表例を記録する

未送信メールがキューに大量に残っている場合、配送を止めるため削除が必要になることがあります。
その前に、件数、最古・最新時刻、代表的な送信元・宛先・キューIDを保存してください。

キューを空にしても、送信スクリプトや漏えいした資格情報が残っていれば再び増えます。
削除後は5分、30分、1時間など間隔を決め、増加が止まったことまで確認します。

WordPress内の送信スクリプト・Cron・フォームを全体調査する

WordPressが送信元なら、wp_mail()だけでなく、PHPのmail()、PHPMailerの直接利用、外部メールAPI、Cronからの呼び出しまで調べます。
攻撃者がWordPress標準の関数を使うとは限らないためです。

不審なPHPは読み取り検索から絞り込む

最初はファイルを変更せず、送信関数、SMTP接続先、APIエンドポイント、難読化された文字列を読み取り検索します。
正規プラグインも同じ関数を使うため、検索結果が出ただけで感染と断定せず、公式配布物との差分、更新日時、呼び出し元を確認してください。

# /path/to/site は実際のWordPressルートへ置き換えます
rg -n --glob '*.php' 'wp_mail\(|mail\(|PHPMailer|SMTP|sendgrid|mailgun' /path/to/site

# WordPress Cronの登録名を読み取り確認します
wp cron event list --fields=hook,next_run_relative,recurrence

コマンドが使えない共有サーバーでは、ファイルマネージャーで更新日時を確認し、WordPress公式配布物や正規プラグインと比較します。
不審なコードを見つけても、その場で編集せず、ファイル名・パス・SHA-256・更新時刻を記録してコピーを保全します。

Cron・Action Scheduler・フォーム連打を確認する

大量送信が一定間隔なら、WP-Cron、Action Scheduler、サーバーCron、自動化プラグインを確認します。
hook名、引数、登録元、次回実行、再登録条件を調べ、単にイベントを削除するだけで終わらせないことが大切です。

送信がフォーム送信のたび増える場合は、CAPTCHAの有無だけでなく、REST APIやadmin-ajax.php経由の直接要求、同一IP・User-Agent、成功応答を調べます。
フォームを無効化する前に、正規問い合わせの保存先と代替連絡手段も準備してください。

クイックレスキュー

WordPressのWP-Cronに不審な処理がある時の確認と安全な削除手順

データベースと管理者権限も確認する

送信先リスト、テンプレート、APIキーがデータベースへ保存されている場合があります。
wp_options、不審な独自テーブル、投稿・メタ、Action Scheduler関連テーブルを調べ、シリアライズされた値を直接置換しないでください。

知らない管理者、Application Passwords、外部連携、SMTPプラグイン設定も確認します。
ファイルを直しても、管理者権限やAPIキーが残れば設定を書き戻される可能性があります。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順

WordPressの迷惑メール原因を止めて認証情報と不審ファイルを復旧する

原因が特定できたら、証拠を保全し、実行経路を止め、正規配布物へ戻し、認証情報を安全な端末から変更します。
順番を守る理由は、先にパスワードだけ変えても、感染中の管理画面や端末から再び盗まれる可能性があるためです。

不審な送信処理は隔離して正規機能を戻す

不審ファイルは公開領域外へ隔離し、WordPress本体は同一バージョンの正規ファイル、テーマ・プラグインは公式または提供元の正規パッケージと比較します。
コアだけを差し替えても、uploads、mu-plugins、未使用テーマ、設定ファイル、データベースに残る処理は消えません。

正規フォームや通知機能まで削除した場合は、送信元・宛先・件名・レート制限を確認してから再構築します。
復旧中はテスト宛先を限定し、外部への大量再送を起こさないようにしてください。

SMTP・サーバー・WordPressの認証情報を変更する

変更対象はSMTPパスワードだけではありません。
レンタルサーバー、SFTP・SSH、WordPress管理者、データベース、Webメール、メールAPI、ドメイン・DNS、外部バックアップの認証情報を棚卸しします。

変更は感染していない端末から行い、不要なセッション、Application Passwords、APIキーを失効します。
共用アカウントをやめ、誰がどの権限を使ったか追える個別アカウントへ分けると再発確認がしやすくなります。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント

WordPressの大量送信停止後は配信テストと再発監視を行う

大量送信が止まったあとは、いきなり全フォームと通知を戻さず、限定宛先で段階的に再開します。
止まったことと正常に届くことは別の確認だからです。

正規メールは1種類ずつテストする

パスワード再設定、問い合わせ、注文、会員通知など、業務上必要なメールを1種類ずつ送信します。
WordPress側の成功、SMTPログへの投入、受信、迷惑メール判定、返信先を記録し、想定外の宛先へ送られていないか確認してください。

テスト中に大量送信が再開したら、直前に戻したプラグイン、Cron、API連携を止め、保存した基準時刻から再調査します。
一度にすべて有効化すると、どの機能が再発源か分からなくなります。

SPF・DKIM・DMARCとブロック状況を確認する

大量送信後は、正規メールまで拒否されたり迷惑メールへ入ったりする場合があります。
SPF・DKIM・DMARCの設定、SMTPサービスのブロック、サーバー会社の制限、主要な拒否応答を確認します。

DNS設定を推測で追加すると、正規の送信元まで認証に失敗することがあります。
実際に使う送信サービスを一覧にし、現在のDNSを保存してから、提供元の手順どおりに修正してください。

24時間・72時間・7日で再発を監視する

復旧直後の24時間は送信数、SMTP認証IP、キュー、PHP更新、管理者操作を重点的に見ます。
72時間では同じ時間帯のCron・フォーム要求を比較し、7日後には平常時の送信数を基準値として通知条件へ反映します。

大量送信が止まっても、同じサーバーの別サイトや古いCMSに不審ファイルがあるなら調査範囲を広げます。
ただしフォルダ名だけで感染を断定せず、公開URL、実行可否、ログ、正規版との差分を確認してください。

クイックレスキュー

WordPressのマルウェア感染でサーバー会社から利用停止された時の確認と再開手順

WordPressの迷惑メール大量送信でよくある質問

WordPressから迷惑メールが送られた時によくある疑問をまとめます。
停止操作で業務メールへ影響する場合は、作業前に代替連絡手段を用意してください。

wp_mailを無効化すれば迷惑メールは完全に止まりますか？

完全とは限りません。不審コードがPHPのmail関数、PHPMailer、外部メールAPI、盗まれたSMTP資格情報を使う場合があります。停止後もSMTPログとサーバーログを照合し、実際の送信経路を確認してください。

SMTPプラグインのログだけで発信元を特定できますか？

ログ対象になった送信は追えますが、プラグインを通らない処理や外部からのSMTP認証は記録されない場合があります。メールヘッダー、SMTPサービス、Web/PHPログ、Cronを合わせて判断します。

メールキューはすぐ全部削除してよいですか？

被害拡大を止めるため削除が必要な場合はあります。ただし件数、時刻、代表的な差出人・宛先・キューIDを先に保存し、削除後に再び増えないことまで確認してください。

正規メールはいつ再開できますか？

不審な送信経路を止め、認証情報を変更し、ファイル・DB・管理者・Cronの確認が終わってからです。限定宛先で1種類ずつ試し、SMTPログと受信結果が一致した後に段階的に戻します。

WordPressからの迷惑メールは停止・追跡・復旧テストの順で対応する

WordPressから大量の迷惑メールが送信された時は、送信停止だけで作業を終えないでください。
完全なメールヘッダーとログを保全し、wp_mail、SMTP認証、メールボックス、外部APIを分けて調べることが再発防止につながります。

不審な送信スクリプト、Cron、フォーム、管理者、APIキーを確認し、正規ファイルへ復旧してから認証情報を変更します。
最後に限定宛先で正常送信を確認し、24時間・72時間・7日の監視へ移してください。

原因が分からない状態で削除と再送を繰り返すと、証拠を失い、メール評価をさらに悪化させるおそれがあります。
現在も送信が続く、サーバー会社から停止警告が来た、正規メールまで届かない場合は、そこで操作を止めて専門家へ相談してください。

WordPressの迷惑メール送信元を自分で特定できない時は

WordPressからの大量送信、SMTP資格情報の悪用、不審な送信スクリプトでお困りなら、
クイックレスキューがログ保全から原因調査・駆除・復旧まで対応します。

このような状態なら、原因を決めつけて削除を続ける前にご相談ください。
送信経路と感染範囲を切り分け、業務メールへの影響も確認しながら復旧します。