「送信元のメールアドレスは、いつも利用している会社のものだった」
「知らないドメインではなかったので、本物だと思った」

不審なメールを見分ける方法として、送信元を確認することは大切です。しかし、送信元の確認だけで、本文やリンク先まで安全と判断することはできません。Googleも、迷惑メールの送信者がメールを認証できる場合があることや、認証以外の情報も組み合わせて判定していることを説明しています。

そこで今回は、受信者が見分ける方法ではなく、**「自社の正規のメール送信機能を、第三者に悪用させないために何を管理するか」**を考えます。

9月の記事では、サービスアカウントやAPIキーの責任者、保管、更新などを扱いました。今回は、メール送信に対象を絞り、送信できる範囲、異常の見つけ方、事故時の停止、業務再開までを整理します。

目標は、単に送信用のパスワードを守ることではありません。自社の名前で何が送られているかを把握し、不正な送信に気付いたとき、必要な範囲を止められる状態を整えることです。

PCデポの公表資料で確認できること

PCデポは2026年9月11日、メール送信用の認証情報を第三者に不正利用され、正規の送信環境からフィッシングメールが送られたと公表しました。同社が提供する「ozzio.jp」のメールアドレスが使われ、確認された送信期間は9月4日9時から8日21時、概算件数は約1,800通としています。

同社の説明によれば、悪用された認証情報には会員情報を閲覧する権限はなく、公表時点で会員データベースなどへの不正アクセスや個人情報の漏えいは確認されていません。問題のアクセスキーの無効化と送信経路の遮断を実施し、不正送信は停止したとしています。

約1,800通は送信されたメールの概算であり、個人情報が漏えいした人数ではありません。 また、認証情報を不正利用されるに至った具体的な経路や、当該メールのSPF・DKIM・DMARCの判定結果は、この公表資料からは分かりません。

以下では、こうした事案を自社の点検へつなげる方法を考えます。本文の管理表、想定例、対応手順は当事業所による提案であり、PCデポの内部構成や実際の対応手順を再現したものではありません。

「送信元の認証」と「内容の安全性」は別の確認

メールの安全対策では、SPF、DKIM、DMARCという仕組みが使われます。それぞれの役割を、今回のテーマに必要な範囲で整理します。

仕組み主に確認・指定すること
SPF配送に使う送信者ドメインについて、その送信サーバーが許可されたものかを確認する。通常、受信画面に表示されるFromアドレスそのものを検証する仕組みではない。
DKIMドメインにひも付く電子署名を検証し、署名対象となった内容の改変などを確認する。
DMARCSPFまたはDKIMの認証結果と、受信画面に表示されるFromのドメインとの整合を確認し、失敗したメールの扱いや報告先を指定する。

これらは、送信ドメインの偽装などに対処するための仕組みです。メールに記載された請求の正当性や、リンク先で求められる操作の安全性を、直接確認するものではありません。

DMARCについては、SPFとDKIMの両方が必ず成功しなければならないわけではありません。少なくとも一方について認証とFromドメインとの整合が成立することが、判定の基本になります。

ここで、正規の送信サービスを利用できる認証情報が、第三者に渡った場面を考えてください。

そのサービスが通常どおりにメールを送り、必要な署名も付ける構成なら、本文が不正な内容でも、送信元の認証条件を満たす可能性があります。これは認証の仕組みから考えられる一般的な状況であり、今回のPCデポのメールが実際に認証を通過したと断定するものではありません。

「認証されたメールだから、本文の指示にも従ってよい」という判断にはしないでください。

同時に、「正規の環境が悪用されるならDMARCは不要」という結論にもなりません。送信元の偽装への対策と、正規の送信機能そのものを守る対策を、両方整える必要があります。

「送信しかできない」は、「被害が小さい」という意味ではない

権限を必要最小限にすることは重要です。しかし、送信権限しか与えていない場合でも、その権限が悪用されたときの影響は検討しなければなりません。

例えば、クラウドのメール配信サービスであるAmazon SESでは、メールを送る操作と、管理操作を分けた権限設定ができます。送信だけを許可する設定は可能ですが、それによって送信される内容の正当性まで保証されるわけではありません。

自社の送信機能を点検する際は、顧客情報を読み取れるかどうかだけでなく、その機能で何を外部へ伝えられるかを考えてください。

会社からのお知らせに見えるメールを送れるのか。請求に関する連絡と同じアドレスを使えるのか。多数の宛先へ一度に送れるのか。こうした点が、確認対象になります。

また、送信サービスへの管理画面に入る認証情報と、プログラムが送信に使う認証情報は、同じとは限りません。Amazon SESでも、管理画面、API、SMTPという利用方法に応じた認証情報が区別されています。

そのため、「管理画面には多要素認証を設定した」という確認だけで、送信経路全体の点検を終えないようにしましょう。プログラムからの送信には何が使われ、その認証情報をどこで管理しているかまで確認します。

社員のメールソフト以外に、誰が自社名で送っているか

自社のメール送信元を調べるとき、従業員のメールアカウントだけを一覧にしていないでしょうか。

ここでは、架空の小規模事業者を考えます。

従業員は普段のメールサービスを使っていますが、問い合わせフォームの自動返信はWebサイトから、請求書の案内は請求管理サービスから、予約確認は予約サービスから送られています。見た目の差出人に同じ会社名が使われていても、実際の送信経路は異なる構成です。

この場合、従業員のメールアカウントだけを点検しても、会社名で送られるメール全体を把握できません。

本記事では、会社の業務から送られるメールを起点に、送信サービスと認証情報を対応付ける「メール送信経路・権限台帳」を作る方法を提案します。

管理項目確認・記録する内容
業務と送信内容問い合わせ返信、請求案内、予約確認、社内通知など
送信元の表示表示名、Fromアドレス、返信先アドレス
実際の送信経路メールサービス、配信サービス、Webサーバー、外部委託先など
送信する主体従業員、業務システム、外部サービス、委託先
認証・接続方法利用アカウント、送信用キーの管理番号、SMTP・API等の方式
認める送信範囲使用できる差出人、宛先、用途、送信量、接続元
通常の利用状況主な送信時間、通常の件数、定期配信の予定
記録と監視送信記録の保管場所、取得できる項目、確認担当者
停止方法と影響どこで停止するか、操作できる人、停止する業務
委託・契約情報契約名義、管理責任者、保守窓口、担当者不在時の連絡先

この台帳には、パスワードや秘密のキーそのものを書き込まないでください。対象を特定する管理番号と、管理担当者や安全な保管場所を記録します。

さらに、メールの差出人として表示するアドレス、返信先、配送エラーの通知先が同じかも確認しましょう。Fromアドレスと、配送に使われる送信者情報は、技術的に別の項目です。

台帳を作る目的は、用語をそろえることではありません。「このメールは、どこから送られ、問題があれば誰が止めるのか」を説明できるようにすることです。

送信権限は、差出人・宛先・用途まで絞る

送信経路が分かったら、各経路にどこまでの権限が必要かを確認します。

例えば、社内の運用担当者へ機器の状態を通知する仕組みなら、社外の任意のアドレスへ送信できる必要があるでしょうか。予約確認の自動送信に、会社のあらゆる差出人アドレスを使う権限が必要でしょうか。

Amazon SESでは、利用する送信操作に応じて、Fromアドレスや宛先、利用する送信元情報などを制限する仕組みがあります。ただし、対応する制限はAPIや接続方法によって異なるため、実際の構成で適用できるかを確認する必要があります。

自社では、まず業務上必要な送信条件を決め、その条件をサービス側の権限設定で制限できるかを確認してください。

宛先が決まっている社内通知なら、送信先を限定する方法を検討できます。一方、不特定のお客様から申し込まれる予約確認では、固定した宛先一覧だけで対応できない場合もあります。その場合は、予約の受付情報と送信先を対応させるなど、業務側で確認する仕組みを考えます。

ただし、差出人を一つに限定しても、そのアドレスから不正な本文を送ることまで防げるとは限りません。

送信権限を狭めることと、送信内容を業務に結び付けることを、別々に確認しましょう。

また、本番用、試験用、用途の異なるシステムで同じ認証情報を使っている場合は、分離を検討してください。試験用の処理を止めるために、顧客向けの重要な通知まで停止する構成になっていないかも確認します。

送信画面の制限を、送信権限の制限と取り違えない

「管理画面では、承認された本文しか送れない」
「プログラムには、一度に送る件数の上限を付けている」

こうした制限を設けていても、その制限が、どの経路に適用されるかを確認する必要があります。

例えば、会社が用意した送信画面では本文の確認や件数制限を行っていても、送信用の認証情報を使って配信サービスへ直接接続できる構成なら、その画面を通らない要求も考慮しなければなりません。

この例で確認したいのは、送信画面の見た目ではなく、認証情報を使える条件です。サービス側の権限、接続元の制限、送信量の管理など、どの部分で拒否する仕組みがあるかを調べます。AWSも、アクセスキーについて、必要な権限だけを与え、想定したネットワークからの利用に制限する方法を案内しています。

一方、接続元を限定しても、その接続元のサーバー自体が不正利用された場合の問題は残ります。したがって、接続元の制限だけで対応を終えず、実際の送信記録と業務記録を照合する仕組みも必要です。

Webフォームについても、送信用キーの流出だけを調査対象にしないようにしましょう。AWSは、問い合わせフォームや紹介機能などが、第三者による不要なメール送信に利用される場合を挙げています。キーを直接盗まれなくても、公開した機能の使われ方に問題がないかを確認する必要があります。

これは、今回のPCデポの原因がWebフォームだったという説明ではありません。自社を点検する際に、認証情報と、送信を受け付ける機能の両方を見るという提案です。

監視は、「一日に何通送ったか」だけで終わらせない

不正送信へ早く気付くには、通常の使い方を把握したうえで、説明のつかない変化を確認する必要があります。

例えば、毎月決まった日に請求案内を送る仕組みなら、その日の送信増加には業務上の理由があります。一方、通常送らない時間帯の送信や、予約件数と合わない確認メールの増加には、理由の確認が必要です。

Amazon SESでは、送信要求、配送、配送失敗、迷惑メールの申告などを、イベントや指標として確認できます。利用できる記録の詳しさは、監視方法や設定によって異なります。

本記事では、送信件数に加え、使われた認証情報、接続元、送信時間、宛先の傾向、差出人、業務上の送信予定を組み合わせて確認する方法を提案します。

例えば、予約システムなら、その日の予約受付件数と確認メールの送信件数を照合します。単純に件数が違うだけで不正と決めるのではなく、再送や変更通知などの理由を確認します。

少数の送信であっても、請求先や支払条件を変える案内など、影響の大きい内容が想定外に送られていれば、調査が必要です。大量送信だけを検知対象にすると、こうした確認が抜けます。

逆に、異常を知らせる通知が出たことだけで、攻撃と断定する必要はありません。正規の配信、設定変更、再試行などの記録と照合してください。

通知先についても、不正利用された場合に停止するメールサービスだけへ依存しない方法を検討しましょう。誰が最初に確認し、確認できなければ誰へ引き継ぐかを決めます。

監視の目標は、数字を見ることではなく、「この送信は、どの業務で説明できるか」を確認することです。

「送信済みフォルダーにない」だけでは、送っていないと判断できない

調査を始める際、「従業員の送信済みフォルダーを見たが、不審メールはなかった」と説明されることがあります。

しかし、先ほどの架空の事業者のように、Webサイトから外部の配信サービスへ直接送信を依頼する構成なら、従業員のメールソフトだけを見ても、その経路の実行状況は分かりません。

確認する場所は、送信経路に合わせて決める必要があります。

例えばAmazon SESのイベント記録には、送信時刻、メッセージの識別番号、宛先などに加え、設定に応じて接続元や呼出し主体などの情報が含まれます。ただし、必要な記録が残るかは、事前の設定を確認してください。

また、DMARCの集計レポートは、送信元や認証状況を確認する材料になりますが、個々のメール本文や社内の送信承認を記録する台帳ではありません。すべての受信先から同じ範囲のレポートを得られるわけでもありません。

したがって、送信サービスの記録、業務システムの処理記録、必要に応じた受信メールの情報を対応付けて確認します。

平時の点検では、テスト用のメールを一通送り、その送信を後から追えるか試してみてください。誰が、どこを見れば、対象の送信を特定できるかを確認しておくことが重要です。

不正送信を止める場所を、事前に決める

不正送信が疑われるときは、原因調査だけでなく、送信が続かないようにする対応が必要です。

このとき、「自社のプログラムを停止すること」と「第三者による送信を止めること」を同じ扱いにしないでください。

送信用の認証情報を使って外部から直接接続されている場合、自社の定期処理を止めても、その認証情報が有効なままなら、別の経路からの利用を止められるとは限りません。

停止方法としては、問題の認証情報の無効化、送信権限の取消し、対象アカウントや送信サービスの停止などを検討します。例えばAmazon SESには、アカウントのメール送信を有効・無効にする機能があります。ただし、停止対象となる範囲や、既に受け付けたメールの扱いは、実際のサービスと構成で確認してください。

一つの経路だけを止められない構成なら、正常な業務への影響も大きくなります。請求案内、予約確認、パスワード再設定など、停止する機能を事前に整理し、代替の連絡方法を決めておきましょう。

ただし、実際に悪用が続いている場合に、通常の更新作業と同じように、業務への影響がなくなるまで古い認証情報を残す判断は避けてください。平時の交換と、事故時の封じ込めは、目的が異なります。

停止の判断者、操作する担当者、委託先が不在の場合の連絡先を決め、送信経路・権限台帳からたどれるようにします。

SPFの変更や社員のパスワード変更だけで、対応を終えない

メールの事故では、異なる設定や認証情報が、まとめて「メールの設定」と呼ばれることがあります。

しかし、社員のログインパスワード、プログラムの送信用キー、DKIMの署名に使う鍵、SPFやDMARCのDNS設定は、役割が異なります。送信元の認証に使う情報と、送信サービスへの利用を許可する情報を分けて確認してください。

例えば、社員が利用するログインパスワードを変更しても、別に発行された送信用の認証情報まで同時に無効化されるかは、サービスの仕様によります。変更した対象と、悪用された経路が一致しているかを確かめましょう。

また、SPFから送信サービスを外す操作は、当該サービスの認証情報を無効化する操作ではありません。受信側の判定に関わる設定変更と、送信そのものの停止を分けて考える必要があります。DMARCも、整合したDKIM認証が成立する場合には、SPFだけの変更で失敗になるとは限りません。

DNS設定を変更すべき場合があっても、それだけを唯一の停止手段にせず、送信サービス側で何を止めるかを管理者や提供者と確認してください。

「何かの設定を変えた」ではなく、「悪用されている権限を使えなくしたか」で確認することが重要です。

送信停止と、調査に必要な記録の保全を並行する

停止作業では、どの認証情報や経路を、いつ、誰が止めたかを記録します。それと並行して、影響範囲を調べるための情報を確保してください。

対象の認証情報、送信期間、送信先、本文や添付の内容、接続元、設定変更の履歴などが確認対象です。ただし、秘密情報そのものを社内の報告書へ貼り付けないようにします。

受信者から不審メールの提供を受ける場合は、管理者が指定する安全な方法で、元のメールやヘッダーなどを受け取ります。確認のためにリンクを開いたり、大勢へ転送したりする必要はありません。

また、件数は意味を分けて整理しましょう。

送信要求が受け付けられた件数、相手のメールサーバーへ届いた件数、異なる宛先の数、受信者から被害の申告があった件数は、同じではありません。Amazon SESでも、送信要求の成功と、宛先メールサーバーへの配送は別のイベントとして扱われています。

「何通送ったか」が分かっても、それだけで「何人がリンクを開いたか」「何人が情報を入力したか」は判断できません。分かることと、記録がなく確認できないことを分けて報告してください。

個人データの漏えい等が発生した、またはそのおそれがある場合は、情報の内容や発生状況に応じて、法令上の報告・本人通知の要否も確認します。不審メールが送られたという事実だけで、一律に漏えいを断定するのでも、一律に報告不要とするのでもありません。個人情報保護委員会は、一定の要件に該当する漏えい等や、そのおそれがある場合の報告を案内しています。

注意喚起で、新たな不審操作を求めない

自社の送信機能が悪用された場合、受信したお客様や取引先へ、何を確認してほしいかを整理します。

本記事では、不審メールの特徴と、確認済みの状況、利用者が取るべき行動、正式な問い合わせ先を分けて案内する方法を提案します。

例えば、公式サイトなどへ掲載する文面は、次のように作れます。

当社のメール送信機能が第三者に不正利用され、当社が依頼していない内容のメールが送信されたことを確認しました。現在、対象の送信経路を停止し、影響範囲を調査しています。該当するメール内のリンクから操作せず、普段お使いの公式アプリや、あらかじめ登録した公式サイトから状況をご確認ください。不審な画面へ認証情報などを入力した場合は、公式窓口へご相談ください。

これは架空の状況に対する案内文です。送信停止が確認できていない場合に「停止しました」と書くなど、事実より先の説明をしないでください。

また、注意喚起のメールで、新しいリンクからパスワードやカード情報を入力するよう求める構成は避け、利用者が普段から使っている確認経路を案内する方法を検討します。

「このアドレスから届くメールは安全です」「今後は当社ドメインをすべて受信許可してください」といった説明にも注意が必要です。認証以外の情報も組み合わせてメールを判定する仕組みを、会社名だけで無効にする案内にはしないことをおすすめします。

問い合わせを受ける担当者には、実際に求める情報と、求めない情報を伝えます。調査の名目でパスワードや認証コードそのものを聞き取る運用にしないでください。

再開は、「新しいキーで送れた」で判断しない

認証情報を入れ替え、テストメールが送れたら、対応は完了でしょうか。

再開前には、古い認証情報の無効化に加え、新しい認証情報を同じ原因で再び使われない状態になっているかを確認する必要があります。

AWSも、認証情報の不正利用への対応として、認証情報の更新だけでなく、利用構成の点検や、不正な利用者・資源の除去などを案内しています。

原因を完全に特定できない段階で再開を検討する場合は、何が未確認なのか、どの範囲を制限するのか、どの監視を追加するのかを明確にし、責任者が判断してください。

また、停止前に登録された配信予約や、送信待ちの処理が残っていないかを確認します。新しい認証情報へ切り替えた直後に、確認していない配信が再開される運用にしないようにしましょう。

次の表は、再開前に使う確認項目の例です。

確認する範囲再開前に確認したいこと
不正利用された権限対象の認証情報や不要な権限が使えなくなっている
認証情報の保管・利用環境調査で判明した問題へ対処し、未確認事項を管理している
送信内容と宛先再開する業務、差出人、送信先、本文や配信予定を確認している
待機中の処理未処理メールや自動再送を確認し、無条件に再実行しない
記録と監視テスト送信を追跡でき、異常時の通知が担当者へ届く
停止と判断再停止できる担当者がいて、再開範囲と条件が承認されている

最初は対象と件数を限定し、想定した送信だけが行われることを確認しながら、段階的に通常運用へ戻す方法を検討してください。

不正送信を止めても、通常のメールが届くかは別に確認する

事故後には、送信機能の安全性だけでなく、通常の業務メールが届く状態かも確認します。

例えばAmazon SESでは、配送失敗や迷惑メール申告の状況などによって、送信機能が審査対象になったり、停止されたりする場合があります。また、提供者が送信を停止した場合、自社側の送信有効化操作だけで再開できるとは限りません。

こうした状態が自社で発生していないかを、利用サービスの管理画面と窓口で確認してください。これは、PCデポで同様の送信制限が起きたと説明するものではありません。

再開試験では、送信要求が成功したことだけでなく、会社が管理するテスト用の宛先で、受信状況も確認します。請求案内や予約確認など、業務ごとの送信元と本文を使い、必要な記録が残るかを確かめます。

顧客へ重要な案内が届いていない可能性がある場合は、メールの再送だけに頼らず、別の連絡方法を検討してください。ただし、問題を解決しないまま別の送信アカウントへ移し、制限を回避するような運用にはしないことが重要です。

不正な送信を止めることと、必要なメールを届けられる状態へ戻すことを、別々の完了条件として管理しましょう。

外部委託先には、「止め方を説明できるか」まで確認する

Webサイトや業務システムを外注している場合、メール送信の仕組みを自社だけでは確認できないこともあるでしょう。

その場合は、委託先へ、送信経路と停止方法を具体的に確認します。

当社名または当社ドメインを使ってメールを送信する機能について、利用サービス、認証方法、許可されている差出人・宛先の範囲、送信記録の取得方法をご提示ください。不正送信が疑われる場合に、どの権限やサービスを誰が停止できるか、停止する業務と連絡窓口も確認したいと考えています。認証情報そのものをメールへ記載する必要はありません。

これは確認依頼の文例です。

回答に「クラウド側で安全に管理しています」と書かれているだけなら、自社の契約で何を確認できるかを追加で尋ねてください。管理画面を見られるのは誰か、ログを取り出せるのは誰か、休日に停止できるのは誰かを明確にします。

特に、委託先の担当者だけが認証情報や契約情報を持っている場合は、担当者交代や契約終了時の引継ぎ方法を決めておきましょう。

自社ですべての技術操作をできる必要はありません。ただし、何が動いているか分からず、止める依頼先も分からない状態は、改善対象です。

訓練では、「自社が送った形跡のないメール」から始める

準備した手順が使えるか、架空の状況で確認してみましょう。

例えば、次のような想定です。

取引先から「御社の予約確認と同じ差出人から、普段と違う案内が届いた」と連絡がありました。従業員の送信済みフォルダーには、そのメールがありません。一方、外部の配信サービスでは、予約の受付件数を上回る送信が記録されています。

この想定から、最初に誰へ連絡し、どの記録を確認するかを考えます。

現場担当者は、受信メールを安全に受け取る窓口を案内できるでしょうか。技術担当者は、対象の送信経路を特定できるでしょうか。責任者は、予約確認メールを一時停止する場合の業務影響を判断できるでしょうか。

途中で「委託先の担当者が不在」「一つのキーを複数業務で共用している」「送信停止後も配信待ちのメールが残っている」という条件を追加すると、台帳と手順の不足を確認できます。

訓練では、本番の顧客へメールを送ったり、実際の不審なリンクを開いたりする必要はありません。架空のメール、検証用の宛先、操作を伴わない確認などを組み合わせます。

評価するのは、攻撃の原因を当てたかどうかではなく、送信経路を特定し、必要な判断を行い、記録を保全しながら止められたかです。

まとめ――会社の「送る権限」も、守るべき業務資産

メールの対策は、受信者へ「気を付けてください」と伝えることだけではありません。

自社の正規の送信機能が悪用されたとき、そのメールを受け取るのは、お客様や取引先かもしれません。送信元の認証を整えることに加え、誰がどの経路から送信できるかを管理する必要があります。

まず、自社で使っている自動送信を一つ選んでください。

どのサービスが、どの認証情報で、どの差出人を使っているのか。通常は何通送り、異常に気付く記録はどこにあるのか。問題があれば、誰が何を止めるのか。

これらを「メール送信経路・権限台帳」へまとめ、実際の設定と照合しましょう。

「送信できるから使う」ではなく、「送信する条件を決め、使われ方を確認し、必要なときに止められるから使う」。

送信権限を管理することは、自社の情報だけでなく、自社からの連絡を信頼している相手を守るための取り組みでもあります。

ライトハウスコンサルタントでは、クラウド、アカウント、社内ルールの現状確認や、インシデント発生時の判断・連絡・復旧方針を確認する机上演習を支援しています。自社のメール送信経路や、委託先との役割分担を整理したい場合は、ご相談ください。

投稿タグ
, , , , , , , , , , , , ,