本文へスキップ
学習センターに戻る安全性

POP3とは?仕組みとセキュリティリスクを解説

Ian BussieresIan Bussieres著2026年11月5日10分で読了

要旨

POP3とは、サーバーからメールを取り込むプロトコルです。仕組み、取得後に削除する方式のリスク、MSPが古いクライアントを保護・廃止する方法を解説します。

POP3とは?仕組みとセキュリティリスクを解説

POP3(Post Office Protocol version 3)とは、昔ながらのメールクライアントがメールサーバーからメッセージを取り込むためのプロトコルです。1996年にRFC 1939で定義されました。クライアントは接続し、ユーザー名とパスワードでログインしてメールをダウンロードし、従来の設定ではサーバー上のコピーを削除します。セキュリティ部門が注意すべき理由は3つあります。メールが保護や保全の難しい端末に散らばること、POP3がMFAを回避するパスワードのみのログインを前提に育ったこと、サーバー上のコピーが消えて保存とインシデント対応に穴が開くことです。MicrosoftとGoogleはどちらもPOP3の基本認証を停止しており、このプロトコルの行く末を示しています。

POP3とは

POP3は、メールクライアントがサーバーからメールを受信する2つの標準的な方法の1つです。1996年5月にRFC 1939(Internet Standard 53)として公開され、ダイヤルアップ時代向けに設計されました。短時間だけ接続してすべてを取り込み、オフラインで読む方式です。このプロトコルが扱うのは受信だけです。送信はSMTPの役割で、複数端末でメールを読む現代的な選択肢はIMAPです。

仕組みが単純なため、POP3はこれまでに出荷されたほぼすべてのデスクトップクライアントに組み込まれています。メールボックスを定期的に確認するスキャナー、チケット管理システム、業務アプリにも多く搭載されています。この普及ぶりこそ、2026年になってもMSPがつまずく理由です。比較はIMAP・POP3・SMTPの違いをご覧ください。

POP3セッションの流れ

RFC 1939はセッションの状態を3つ定めています。AUTHORIZATION(ログイン)、TRANSACTION(メールの一覧と取得)、UPDATE(削除の反映と切断)です。典型的なセッションは次のとおりです。

技術的な例text
S: +OK POP3 server ready
C: USER alice@example.com
S: +OK
C: PASS ********
S: +OK maildrop has 2 messages (620 octets)
C: LIST
S: +OK 2 messages (620 octets)
C: RETR 1
S: +OK 320 octets
S: <message content>
C: DELE 1
S: +OK message 1 deleted
C: QUIT
S: +OK POP3 server signing off

セキュリティ上、この流れで重要な点は3つです。

  1. 認証は単純なUSER/PASSの組み合わせです。基本のプロトコルでは、毎回のセッション開始時に固定の認証情報を送ります。オプションの仕組み(APOP、SASL)もありますが、共通して使える最低限の方式は使い回せるパスワードです。
  2. DELEは削除マークを付けるだけです。クライアントがQUITを送り、サーバーがUPDATE状態に入るまで何も消えません。UPDATE状態でマーク済みのメッセージがすべて削除されます。接続が切れるとメールボックスはそのまま残るため、削除したはずのメールが再び現れることがあります。
  3. 「サーバーにコピーを残す」はクライアントの設定で、標準の動作ではありません。この機能があるクライアントは、オプションのUIDLコマンドで取得済みのメッセージを記憶します。チェックを外していると、ダウンロードが終わった時点でサーバー上のコピーは消えます。

POP3のポート番号と許可すべきポート

ポート内容推奨
110平文のPOP3(STLSでの暗号化は任意)文書化されたレガシー機器が必要としない限り、ファイアウォールでブロック
995暗黙的TLS上のPOP3(「POP3S」)POP3がまだ必要な場合のみ許可
143 / 993平文のIMAP/暗黙的TLS上のIMAP同様:993を優先し、143をブロック

この議論は2018年にIETFが決着させました。「Cleartext Considered Obsolete」と題したRFC 8314は、メールクライアントとメールサーバー間のすべての通信にTLS 1.2以降を推奨しています。また、平文の110番ポートの接続をSTLSで暗号化するより、995番ポートでの暗黙的TLSを優先しています。NISTのSP 800-177 Rev. 1もPOPとIMAPのクライアントに同じ助言をしています。TLSで接続すべきとし、暗号化されていない接続でのユーザー名とパスワードによる認証を「強く推奨しない」としています。STLSなしの110番ポートでは、ユーザー名、パスワード、メッセージの全文が、盗聴できる立場の誰にでも読める状態でネットワークを流れます。TLSがセッションを守る仕組みに詳しくない場合は、まずそちらをご覧ください。

セキュリティ部門がPOP3に注意すべき理由

最大の問題は認証情報です。実務でPOP3といえば基本認証です。MFAに対応できないクライアントが、多くは数分おきの受信確認のたびに固定のパスワードを送ります。プロバイダーはこれを維持できないと判断しました。MicrosoftはExchange OnlineのPOPとIMAPで、2022年10月1日から基本認証を無効化しており、再び有効にすることはできません。現在POP/IMAPにはOAuth 2.0が必要です。Googleも続き、2025年3月14日以降、Google WorkspaceはPOP、IMAP、SMTP、CalDAV、CardDAVでパスワードのみのサインインを受け付けていません。残る手段はOAuth(またはアプリパスワード)だけです。今もパスワードだけで接続するPOP3クライアントの相手は、オンプレミスか小規模なホスティングのサーバーです。レガシープロトコルは最新のサインイン時の確認を経ないため、こうしたアカウントは認証情報の窃取の格好の標的になります。

メールが端末に散らばります。ダウンロード後、メッセージの唯一のコピーが一台のノートPCのメールファイルにしかないこともあります。ノートPCを失えば、メールも失います。添付ファイルもそのままディスクに保存されるため、ゲートウェイのフィルタリングとエンドポイント保護に頼るしかありません。悪意のある添付ファイルの扱い方もご覧ください。

調査が難しくなります。サーバー上のコピーが消えると、インシデント対応や電子情報開示の際に、一元的に検索できるものが残りません。対応担当者はメール基盤を検索する代わりに、端末のイメージを取得しなければなりません。顧客が保存義務(HIPAA、金融規制、サイバー保険の要件)の対象なら、ダウンロード後に削除する方式のせいで、気づかないうちにコンプライアンス違反になりかねません。

POP3とIMAPの違い

IMAPはメールをサーバーに保持し、既読・未読、フォルダ、削除をすべての端末で同期します。POP3はメールを一台の端末に取り込み、標準ではサーバーから削除します。セキュリティとコンプライアンスの観点では違いは明確です。IMAPはバックアップ、検索、保全ができるデータを一元管理し、POP3はそれを端末ごとに分散させます。POP3が勝る場面はほとんど残っていません。厳しい容量制限のあるサーバーを一台の端末だけで使うユーザーか、ほかのプロトコルに対応しないレガシー機器くらいです。これらは期限付きの例外として扱い、恒久的な構成にはしないでください。

POP3をすぐ廃止できない場合の保護方法

  1. まず棚卸しをします。各メール基盤のサインインやプロトコルのログから、POP3を使う全アカウントとそのクライアント、理由を一覧にします。サービス用メールボックス、スキャナーやチケット管理の連携、移行していない少数の個人が見つかるはずです。
  2. TLSを強制します。RFC 8314に沿い、995番のみ許可し、110番の平文ログインを無効化、TLS 1.2以上を必須にします。
  3. パスワードだけの認証をなくします。Microsoft 365とGoogle Workspaceでは対応済みです。それ以外では、OAuth対応のクライアントか固有のアプリパスワードを必須にし、アカウント自体にMFAを適用します。
  4. 管理下のクライアント設定で「サーバーにコピーを残す」を有効にします。ゲートウェイでもアーカイブし、クライアントがダウンロードする前にコピーを残します。
  5. アカウントを監視します。新しいIP範囲や国からのPOP3ログイン、ログイン失敗の急増、一回のセッションでのメールボックス全体のダウンロードにアラートを設定します。いずれも低コストで精度の高い、アカウント乗っ取りの検知方法です。
  6. 移行期限を決めます。ユーザーをIMAPかクラウドのネイティブクライアントに移し、メールボックスを確認する連携はAPIに置き換えます。

POP3とSPF・DKIM・DMARCの関係

直接の影響はありません。SPF、DKIM、DMARCは、メールがメールボックスに届く前に受信サーバーで認証します。POP3ユーザーがダウンロードするメッセージは、すでにこれらのチェックに合格または不合格になっています。受信と送信者認証は別の層であり、両方が必要です。ただし注意点が2つあります。DMARCが守るのは自社の正確なドメインだけで、フィッシング犯が登録する類似ドメインは守れません。また、基本的なPOP3クライアントはWebメールより視覚的な警告が少ないため、チェックに失敗しても届いたメールが見過ごされやすくなります。受信側のレガシーなアクセスを整理する間に、Palisadeの無料のメールセキュリティスコアで顧客のドメインを調べ、送信側も確認しましょう。

よくあるトラブル

POP3クライアントが突然Microsoft 365やGmailにサインインできなくなった。パスワードの誤りではなく、基本認証が廃止されたためです。Exchange OnlineではPOP/IMAPにOAuthが必要です(また、OutlookクライアントでPOPとIMAPのOAuthに対応する予定はないとMicrosoftは述べています)。Google WorkspaceではOAuthかアプリパスワードが必要です。対処法:OAuth対応のクライアントに切り替えるか、ポリシーが許す範囲でアプリパスワードを発行します。

誰かがデスクトップクライアントを設定した後、Webメールからメールが消えた。POP3の標準動作である、ダウンロード後の削除が働いた結果です。クライアントで「メッセージをサーバーに残す」を有効にし、コピーが削除されていればゲートウェイのアーカイブやバックアップから復元します。

同じメッセージが重複してダウンロードされる。クライアントがUIDLのキャッシュを失ったか、サーバーがUIDLに対応していないため、取得済みのメッセージを判別できません。キャッシュを消去し、サーバー側のUIDL対応を確認します。

110番ポートへの接続がタイムアウトする。ファイアウォールが(正しく)ブロックしています。例外を申請せず、SSL/TLSで995番ポートを使うようクライアントを設定し直します。

接続時に証明書エラーが出る。多くの場合、クライアントが誤ったホスト名(プロバイダーのメールホストではなくドメイン)を指しているか、サーバーの証明書が期限切れか、TLSが1.2未満です。まずサーバー名を修正します。

関連記事

よくある質問

よくある質問

2026年でもPOP3は安全に使えますか?

安全に使えますが、補完的な対策をすべてそろえた場合に限ります。995番ポートでのTLS、パスワード単体ではなくOAuthかアプリパスワード、サーバー側のコピーかゲートウェイでのアーカイブ、アカウントの監視です。1996年のプロトコルを支えるには手間がかかりすぎます。そのため多くの顧客にとって現実的な答えは、IMAPかクラウドのネイティブメールへの移行です。

顧客環境で110番ポートを塞ぐべきですか?

はい。ほぼすべての環境でブロックすべきです。110番ポートは標準で認証情報を平文で送ります。これはRFC 8314が時代遅れと宣言し、NIST SP 800-177が強く推奨しない方式です。ブロックしたうえで不具合が出ないか監視し、本当に必要なレガシー機器は置き換えを計画する間、隔離します。

POP3はMicrosoft 365やGmailで今も使えますか?

プロトコル自体は使えますが、パスワードのみのサインインは使えません。Exchange Onlineは基本認証の無効化(2022年10月から)以降、POP/IMAPにOAuthを必須にしています。Google Workspaceは2025年3月14日に、パスワードだけでサインインするアプリのアクセスを停止しました。OAuthに対応できないクライアントは、許可されていればアプリパスワードを使うか、置き換えが必要です。

POP3で端末間の同期はできますか?

いいえ。POP3には、フォルダ、既読状態、複数クライアントという概念がありません。「サーバーにコピーを残す」を使えば別の端末でも同じメッセージをダウンロードできますが、何も同期されません。複数の端末でメールを読むなら、IMAPかクラウドのネイティブクライアントが必要です。

プロバイダーがPOP3の基本認証廃止にこだわる理由は?

接続のたびに送られる固定のパスワードは、最も盗みやすく再利用しやすい認証情報であり、レガシープロトコルはMFAを回避するからです。Microsoftの廃止通知もまさにそう述べています。基本認証は攻撃者が認証情報を盗むのを容易にし、MFAの適用を難しく、場合によっては不可能にします。Googleの安全性の低いアプリの廃止も同じ考え方です。日々の運用への影響はMicrosoftのメール認証要件をご覧ください。

メール認証の管理をもっと簡単に

Palisadeで始める。

今すぐ開始

この記事を共有

Ian Bussieres

執筆者

Ian Bussieres

Palisade 共同創業者・CTO

Ian BussieresはPalisade共同創業者兼CTO。PalisadeはIT部門・MSP向けのエージェント型DMARC。

Ianの記事 →