メインコンテンツへスキップ
ブログ一覧に戻る
Web制作・運用

メールプロトコル入門: SMTPからIMAPまで

2023年10月25日
最終更新: 2026年10月8日
7分で読めます

この記事でわかること

メール送受信を支えるSMTP、POP3、IMAPプロトコルの基本を解説します。

メール設定で迷ったら、最初に「送る接続」と「届いたメールを読む接続」を分けます。SMTP、POP3、IMAPは同じ役割の選択肢ではありません。送信だけ失敗するのか、別端末で既読がそろわないのかによって、確かめる場所が変わります。

30秒で要点

  • SMTPはメールの投稿やサーバー間の転送に使います。POP3・IMAPはメールボックスへのアクセスを担います。
  • POP3の取得と削除は別の操作です。IMAPの同期も、削除前の状態へ戻せるバックアップとは区別します。
  • サーバー名・ポート・TLS方式・認証方法はセットで確認します。番号だけを別のサービスから流用しません。
SMTPの投稿と配送からメールボックスへ進み、IMAPまたはPOP3でアクセスする役割の違い。同期とは別に復元用保存を確認する。
役割を整理した概念図です。特定サービスの実通信経路や配送成功を示しません。

送信・配送・閲覧を一枚の地図にする

郵便にたとえると、送信アプリから受付に渡す段階と、配送拠点間で運ぶ段階、届いた物を読む段階は別です。ただしメールではコピーや同期も起きるため、実物の郵便と一対一には対応しません。

メールの基本的な流れ(役割を示した教材)
1. 送信アプリ → 投稿を受け付けるサーバー(SMTP submission)
2. 送信側サーバー → 受信側サーバー(SMTP relay)
3. 受信側の配送処理 → 受信者のメールボックス
   受信アプリ ↔ メールボックス(IMAP または POP3)

3の内部処理が、必ずインターネット上のSMTP接続一本で済むという意味ではありません。Webメールの画面と利用者の間は、別にHTTPSなどの通信を使います。

RFC 6409は、利用者からの投稿とサーバー間の転送を区別しています。サーバーがメールを受け付けても、それだけで相手が読んだことにはなりません。RFC 5321の受付後の責任は配送や失敗時の扱いについてであり、開封の保証ではありません。

ポート番号は接続の役割と組にする

表が収まらない場合は、横にスクロールできます

接続の役割代表的なポート読み方
サーバー間のSMTP転送25通常のメールアプリの投稿設定とは区別する
SMTP投稿+STARTTLS587接続後にTLSへ切り替える方式。TLS必須設定を確認する
SMTP投稿+Implicit TLS465接続の初めからTLSを使う方式
POP3+Implicit TLS995メール取得の接続をTLSで保護する
IMAP+Implicit TLS993メールボックスへのアクセスをTLSで保護する
従来のPOP3 / IMAP110 / 143番号だけで暗号化済みとは判断できない
RFC 8314の対象はメール投稿・アクセスの通信です。「SSL」と表示される設定名を見て古いSSL方式を選ぶのではなく、提供者が指定する現在のTLS方式に合わせます。同RFCは適切にTLSを必須とした587のSTARTTLSと465のImplicit TLSについて説明しています。465という番号だけで常に安全、587なら常に危険という二分法にはなりません。

具体的なサービスのホスト名、認証方式、アプリ用パスワードの要否はそのサービスの公式設定で確認してください。本記事は特定サービスへの接続、資格情報の入力、実送信を行う手順ではありません。

POP3:取得したら必ず消える、ではない

POP3は、サーバー上のメールをクライアントへ取得するためのプロトコルです。RFC 1939では、取得するRETR、削除対象として印を付けるDELE、更新段階へ進むQUITが別になっています。

したがって「ダウンロードした瞬間に必ずサーバーから消える」は不正確です。クライアントの「サーバーに残す」設定や削除の扱いを調べる必要があります。サーバーに残したとしても、複数端末の既読やフォルダー状態がIMAPと同様に同期されると考えないでください。

一台の端末に保存する運用では、その端末の故障、紛失、保存先の容量も判断材料です。端末へ取り込めたことと、別の場所へ復元可能なコピーがあることは別に確認します。

IMAP:同期と復元できる保存を分ける

RFC 9051は、サーバー上のメールやメールボックスを扱うこと、オフライン後に状態を合わせ直すことを説明しています。複数端末でメールを扱いたい場合の候補ですが、オフラインでどこまで読めるかはアプリの保存設定や実装にも依存します。

同期で削除状態が他の端末へ反映される場合、同じ状態の端末が増えても削除前の保管にはなりません。復元期間、管理者が戻せる範囲、独立したエクスポートやバックアップを別に確認しましょう。

表が収まらない場合は、横にスクロールできます

判断材料POP3で確認することIMAPで確認すること
保存場所端末保存とサーバーに残す設定サーバーと端末キャッシュの範囲
複数端末二重取得や削除設定の違い同期される状態と反映の確認
オフライン取得済みの内容を読める範囲事前保存した内容を読める範囲
容量・負荷保存件数、取得頻度、サービス制限同期対象、添付、サービス制限
復旧端末故障時に戻せるか同期削除前の状態へ戻せるか

プロトコル名だけから、どちらのサーバー負荷が低いか、どれだけ容量が必要かは決めません。実際の件数、添付容量、保持期間、アプリの動作が必要です。

架空のチームで選定条件を埋める

たとえば、小さな制作会社で担当者が仕事用PCと貸与スマートフォンを使うとします。まず「両方で既読とフォルダーをそろえたい」を条件にし、IMAP対応のサービスとアプリを候補にします。次に、飛行機など通信できない時間に読む必要があるメールを、事前保存できるか確認します。

最後に、練習用メール一通を対象に、別端末への状態反映と、誤削除時の復元方法を管理者の手順で確かめます。これは利用者が自分の管理下で行う選定案であり、本記事で実施した試験ではありません。実業務のメールを使った削除試験は避けます。

一台だけの保存端末を使う別の運用なら、POP3も比較候補です。その場合も「接続が不安定だからPOP3」と即決せず、オフライン保存、同期の必要性、故障時の復旧を同じ表で比べます。

症状を一つに絞って問い合わせる

表が収まらない場合は、横にスクロールできます

症状記録する事実混同しないこと
読めるが送れない投稿側のサーバー名、方式、エラー受信設定が正しいことは送信設定の証明にならない
一台だけ既読が違う接続方式、アプリ、同期時点ネットワークが使えることは同期完了と同じではない
送信済みだが届かない時刻、宛先の誤り、配送失敗通知送信アプリの表示は開封通知ではない
削除が別端末にも反映同期設定と復元可能期間同期端末をバックアップと数えない

問い合わせの記録にはパスワードやメール本文を貼りません。TLSは接続経路の保護であり、迷惑メール判定の回避、なりすまし対策全体、内容のエンドツーエンド暗号化を一つで保証する仕組みではありません。

よくある質問(FAQ)